管理および設定ガイド

JBoss Enterprise Application Platform 6

JBoss Enterprise Application Platform 6 向け

エディッション 2

Sande Gilda

David Le Sage

Red Hat Red Hat

Darrin Mison

David Ryan

Misty Stanley-Jones

概要

本書は、JBoss Enterprise Application Platform 6 およびそのパッチリリースに関する管理および設定ガイドです。

前書き

第1章 JBoss Enterprise Application Platform の管理に関する入門書

1.1. JBoss Enterprise Application Platform 6 の紹介

JBoss Enterprise Application Platform 6 はオープンな標準に基づいて構築された Java EE に準拠するミドルウェアプラットフォームです。高可用性クラスタリング、強力なメッセージング、分散キャッシングなどの技術を JBoss Application Server 7 と統合し、安定したスケーラブルな高速プラットフォームを作成します。さらに、安全で強力かつスケーラブルな Java EE アプリケーションを迅速に開発できる API や開発フレームワークも含まれています。

1.2. JBoss Enterprise Application Platform 6 の新しい機能と変更された機能

  • JBoss Enterprise Application Platform 6 は、Java Enterprise Edition 6 の Full Profile および Web Profile の仕様の認定された実装です。
  • 管理対象ドメインは、複数のサーバーインスタンスおよび物理ホストを一元管理し、スタンドアローンサーバーは単一のサーバーインスタンスを可能にします。
  • 設定、デプロイメント、ソケットバインディング、モジュール、拡張、およびシステムプロパティはすべて、サーバーグループ別に管理できます。
  • 管理コンソールと CLI は、ドメインまたはスタンドアローン JBoss Enterprise Application Platform 6 インスタンスを管理する新しいインターフェースです。XML 設定ファイルを手作業で編集する必要がなくなりました。管理 CLI ではバッチモードも提供され、管理タスクを処理するスクリプトを作成し、自動化できます。
  • セキュリティードメインなどのアプリケーションセキュリティーは、設定を簡素化できるよう一元管理されています。
  • JBoss Enterprise Application Platform 6 のディレクトリーレイアウトは単純化されました。modules/ ディレクトリーには、共通およびサーバー固有の lib/ ディレクトリーの代わりにアプリケーションサーバーモジュールが含まれるようになりました。domain/ および standalone/ ディレクトリーには、ドメインおよびスタンドアローンデプロイメント用のアーティファクトおよび設定ファイルが含まれます。
  • 各種モジュールがオンデマンドでロードおよびアンロードされるように、クラスローディングメカニズムが完全にモジュール化されました。このため、パフォーマンスおよびセキュリティ面で利点があるだけでなく、非常に短時間で起動や再起動を行うことができます。
  • データソース管理も単純化されました。データベースドライバーは、他のサービスと同様にデプロイできます。また、管理コンソールまたは管理 CLI で直接データソースを作成および管理できます。
  • JBoss Enterprise Application Platform 6 の起動および終了が非常に速くなります。これは、特に開発者にとって利点があります。少ないリソースが使用されるため、システムリソースの使用が非常に効率的になります。

第2章 アプリケーションサーバー管理

2.1. アプリケーションサーバーの管理

JBoss Enterprise Application Platform 6 は、必要なときに実装を設定および管理できる複数の管理ツールを提供します。これらの管理ツールには、新しい管理コンソールや管理コマンドラインインターフェース (CLI) が含まれます。基礎となる管理 API を使用すると、上級ユーザーは必要に応じて独自のツールを開発できます。

2.2. インストールの構造および詳細

JBoss Enterprise Application Platform 6 には、以前のバージョンと比べて単純なディレクトリー構造が含まれます。ディレクトリー構造のリストと、ディレクトリーの内容の説明は以下のとおりです。

表2.1 最上位のディレクトリとファイル

名前 目的
appclient/ アプリケーションクライアントコンテナの設定詳細が含まれます。
bin/ Red Hat Enterprise Linux および Microsoft Windows 用 JBoss Enterprise Application Platform 6 向け起動スクリプトが含まれます。
bundles/ JBoss Enterprise Application Platform 6 の内部機能に関する OSGi バンドルが含まれます。
docs/ ライセンスファイル、スキーマ、およびサンプル
domain/ JBoss Enterprise Application Platform 6 が管理対象ドメインとして実行された時に使用される設定ファイル、デプロイメントコンテンツ、および書き込み可能領域。
modules/ サービスが要求したときに JBoss Enterprise Application Platform 6 により動的にロードされるモジュール。
standalone/ JBoss Enterprise Application Platform 6 がスタンドアローンサーバーとして実行された場合に使用される設定ファイル、デプロイメントコンテンツ、および書き込み可能領域。
welcome-content/ デフォルトインストールのポート 8080 で利用可能な Welcome Web アプリケーションにより使用されるコンテンツが含まれます。
jboss-modules.jar
モジュールをロードするブートストラップメカニズム。

表2.2 domain/ ディレクトリーにあるディレクトリー

名前 目的
configuration/ 管理ドメイン用の設定ファイル。これらのファイルは管理コンソールや管理 CLI で変更し、直接編集するためのものではありません。
data/ デプロイされたサービスの情報。サービスは、デプロイメントスキャナーではなく、管理コンソールや管理 CLI を使用してデプロイするため、このディレクトリーにファイルを手動で置かないようにしてください。
log/ ローカルインスタンスで実行されるホストおよびプロセスコントローラー用実行時ログファイルが含まれます。
servers/ ドメイン内の各サーバーインスタンス用の同等の data/log/、および tmp/ ディレクトリーが含まれます。これらのディレクトリーには、最上位の domain/ ディレクトリー内の同じディレクトリーに類似したデータが含まれます。
tmp/ 管理対象ドメインに対してローカルユーザーを認証するために管理 CLI で使用される共有キーメカニズムに関するファイルなどの一時データが含まれます。

表2.3 standalone/ ディレクトリーにあるディレクトリー

名前 目的
configuration/ スタンドアローンサーバー用の設定ファイル。これらのファイルは管理コンソールや管理 CLI で変更し、直接編集するためのものではありません。
deployments/ デプロイしたサービスの情報。スタンドアローンサーバーには、デプロイメントスキャナーが含まれているため、このディレクトリにデプロイ用のアーカイブを置くことができます。しかし、管理コンソールあるいは管理 CLI を使いデプロイメントを管理する方法が推奨されます。
lib/ スタンドアローンサーバーモードに関連する外部ライブラリ。デフォルトは空です。
tmp/ サーバーに対してローカルユーザーを認証するために管理 CLI で使用される共有キーメカニズムに関連するファイルなどの一時データが含まれます。

2.3. JBoss Enterprise Application Platform 6 プロファイル

JBoss Enterprise Application Platform の以前のバージョンで使用されたプロファイルのコンセプトは使用されなくなりました。JBoss Enterprise Application Platform 6 では、設定に関するすべての情報を保持する少数の設定ファイルが使用されるようになりました。
モジュールとドライバーは必要に応じてロードされるため、JBoss Enterprise Application Platform 6 の以前のバージョンで使用されたデフォルトプロファイルのコンセプト (プロファイルはサーバーを効率的に起動するために使用されます) は適用されません。デプロイメント時に、モジュールの依存関係が確認され、順番付けされ、サーバーあるいはドメインコントローラーによって解決された後に、正しい順番でロードされます。デプロイメント解除時は、デプロイメントで必要なくなった時点でモジュールがアンロードされます。
設定からサブシステムを削除することにより、手動で、モジュールを無効にしたり、ドライバーまたは他のサービスをデプロイ解除したりすることができます。ただし、ほとんどの場合、これは不必要です。アプリケーションでモジュールが使用されない場合、モジュールはロードされません。

2.4. Enterprise Application Platform の設定ファイル

Enterprise Application Platform 6 の設定は、以前のバージョンから大幅に変更されました。最も大きな違いの 1 つは、単一設定ファイルの使用です。このファイルの名前は、サーバーが管理ドメインとして稼働しているか、スタンドアロンサーバーとして稼働しているかに応じて domain.xml または standalone.xml になります。ファイルのデフォルトの場所は、サーバーが管理ドメインとして稼稼働しているか、スタンドアロンサーバーとして稼動しているかによって異なります。

表2.4 domain.xml の場所

サーバーモード 場所
管理ドメイン EAP_HOME/domain/configuration/domain.xml
スタンドアロンサーバー EAP_HOME/standalone/configuration/standalone.xml
これらはデフォルトの場所です。実行時に異なる設定ファイルを指定できます。

2.5. 管理 API

2.5.1. 管理アプリケーションプログラミングインターフェース (API)

管理クライアント

JBoss Enterprise Application Platform 6 は、サーバーを設定および管理する 3 つの方法 (Web インターフェース、コマンドラインクライアント、および XML 設定ファイルのセット) を提供します。設定ファイルを編集する推奨される方法には管理コンソールと管理 CLI が含まれますが、これら 3 つの方法で設定に行われた編集は、さまざまなビューで常に同期され、最終的に XML ファイルに永続化されます。サーバーインスタンスの実行中に XML 設定ファイルに行われた編集は、サーバーモデルによって上書きされることに注意してください。

HTTP API

管理コンソールは、Google Web Toolkit (GWT) で構築された Web インターフェースの例です。管理コンソールは、HTTP 管理インターフェースを使用してサーバーと通信します。HTTP API エンドポイントは、管理レイヤーと統合するために HTTP プロトコルに依存する管理クライアントのエントリポイントです。HTTP API エンドポイントは、 JSON エンコードプロトコルと de-typed な RPC スタイル API を使用して管理対象ドメインまたはスタンドアロンサーバーに対して管理操作を定義および実行します。HTTP API は Web コンソールによって使用されますが、さまざまな他のクライアントに対して統合機能を提供します。

HTTP API エンドポイントはドメインコントローラーまたはスタンドアロンサーバーインスタンスと共存します。HTTP API エンドポイントサービスは、管理操作を実行するためのコンテキストと Web インターフェースにアクセスするためのコンテキストの 2 つの異なるコンテキストを処理します。デフォルトでは、ポート 9990 で実行されます。

例2.1 HTTP API 設定ファイルの例

<management-interfaces>
    [...]
    <http-interface interface="management" port="9990"/>
<management-interfaces>
Web コンソールは、HTTP 管理 API と同じポートを介して提供されます。デフォルトの localhost でアクセスされる管理コンソール、特定のホストとポートの組み合わせによってリモートでアクセスされる管理コンソール、および公開されたドメイン API を区別することが重要です。

表2.5 TableTitle

URL 説明
http://localhost:9990/console ローカルホストでアクセスされる管理コンソール (管理対象ドメイン設定を制御します)。
http://hostname:9990/console リモートでアクセスされる管理コンソール (ホストを指定し、管理対象ドメイン設定を制御します)。
http://hostname:9990/management HTTP 管理 API は管理コンソールと同じポートで実行され、API に公開された raw 属性と値を表示します。
ネイティブ API

ネイティブ API ツールの例には管理 CLI があります。この管理ツールは管理対象ドメインまたはスタンドアロンサーバーインスタンスに使用できるため、ユーザーはドメインコントローラーまたはスタンドアロンサーバーインスタンスに接続して、de-typed 管理モデルを介して利用可能な管理操作を実行できます。

ネイティブ API エンドポイントは、管理レイヤーと統合するためにネイティブプロトコルに依存する管理クライアントのエントリポイントです。管理操作を定義および実行するために、オープンバイナリプロトコルと、非常に少数の Java タイプに基づいた RPC スタイル API を使用します。これは、管理 CLI 管理ツールによって使用されますが、さまざまな他のクライアントの統合機能も提供します。
ネイティブ API エンドポイントはホストコントローラーまたはスタンドアロンサーバーと共存します。管理 CLI を使用するには、これを有効にする必要があります。デフォルトでは、ポート 9999 で実行されます。

例2.2 ネイティブ API 設定ファイルの例

<management-interfaces>
    <native-interface interface="management" port="9999"/>
    [...]
<management-interfaces>

2.6. JBoss Enterprise Application Platform の起動

2.6.2. スタンドアローンサーバーとして JBoss Enterprise Application Platform 6 を起動

Red Hat Enterprise Linux。
コマンドの実行: EAP_HOME/bin/standalone.sh
Microsoft Windows Server。
コマンドの実行: EAP_HOME\bin\standalone.bat
オプション:別のパラメーターを指定します。
起動スクリプトに渡すことができる他のパラメーター一覧を出力するには、-h パラメーターを使います。
結果

JBoss Enterprise Application Platform 6 スタンドアロンサーバーインスタンスが起動します。

2.6.3. 管理ドメインとして JBoss Enterprise Application Platform 6 を起動

Red Hat Enterprise Linux。
コマンドの実行: EAP_HOME/bin/domain.sh
Microsoft Windows Server。
コマンドの実行: EAP_HOME\bin\domain.bat
オプション:起動スクリプトに追加パラメーターを渡す
起動スクリプトに渡すことができる各種パラメーターを確認するには、-h パラメーターを使います。
結果

JBoss Enterprise Application Platform 6 監理対象ドメインインスタンスが起動します。

2.6.4. 別の設定で Enterprise Application platform を起動

タスクの概要

設定ファイルを指定しない場合、サーバーはデフォルトファイルで起動します。しかし、サーバーを起動してから設定を手動で指定することができます。このプロセスは管理ドメインを使うか、スタンドアローンサーバーを使うか、またどのオペレーティングシステムを使うかで少し変わってきます。

タスクの前提条件

別の設定ファイルを使う前に、デフォルト設定をテンプレートとして使い別設定ファイルの作成準備をします。管理ドメインの場合は、設定ファイルをEAP_HOME/domain/configuration/に置く必要があります。また、スタンドアローンサーバーは、設定ファイルをEAP_HOME/standalone/configuration/に置いて下さい。

注記

設定サンプルが複数 configuration ディレクトリに含まれています。これら使いクラスタリングや Transaction XTS API など、追加機能を有効にします。
  1. 管理ドメイン

    管理ドメインでは、設定ファイルのファイル名をオプションとして--domain-config パラメーターに渡します。設定ファイルが EAP_HOME/domain/configuration/ にある場合は、全パスを渡す必要はありません。

    例2.3 Red Hat Enterprise Linux 上の管理ドメインで別の設定ファイルを利用

    [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml

    例2.4 Microsoft Windows サーバー上の管理ドメインで別の設定ファイルを利用

    C:\EAP_HOME\bin> domain.bat --domain-config=domain-alternate.xml
  2. スタンドアローンサーバー

    管理ドメインでは、設定ファイルのファイル名をオプションとして--server-config パラメーターに渡します。設定ファイルが EAP_HOME/domain/configuration/ にある場合は、設定ファイルの全パスを渡す必要はありません。

    例2.5 Red Hat Enterprise Linux 上のスタンドアローンサーバーで別の設定ファイルを利用

    [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml

    例2.6 Microsoft Windows サーバー上のスタンドアローンサーバーで別の設定ファイルを利用

    C:\EAP_HOME\bin> standalone.bat --server-config=standalone-alternate.xml
結果:

Enterprise Application Platform が別設定を使い実行されました。

2.6.5. Enterprise Application Platform の停止

タスク概要:

Enterprise Application Platform を停止する方法は、起動方法によって異なります。このタスクでは、対話的に起動されたインスタンスを停止し、サービスにより起動されたインスタンスを停止して、スクリプトによりバックグラウンドにフォークされたインスタンスを停止します。

注記

このタスクはドメイン内のサーバーまたはサーバーグループを停止しません。これらのシナリオの詳細については、「管理コンソールを使用したサーバーの停止」 を参照してください。

手順2.1 タスク:

  1. コマンドラインプロンプトから対話的に起動したインスタンスを停止します。

    Enterprise Application Server が実行されているターミナルで Ctrl-C を押します。
  2. オペレーティングシステムサービスとして起動されたインスタンスを停止します。

    オペレーティングシステムに応じて、以下のいずれかの手順を実行します。
    • Red Hat Enterprise Linux

      Red Hat Enterprise Linux の場合に、サービススクリプトを記述したときは、stop 機能を使用します。これは、スクリプトに記述する必要があります。次に、service scriptname stop を使用できます。ここで、scriptname はスクリプトの名前です。
    • Microsoft Windows Server

      Microsoft Windows の場合は、net service コマンドを使用するか、コントロールパネルの [サービス] アプレットからサービスを停止します。
  3. バックグラウンドで実行されているインスタンスを停止します (Red Hat Enterprise Linux)。

    1. プロセスリストからインスタンスを特定します。1 つのオプションは、コマンド ps aux |grep "[j]ava -server" を実行することです。これにより、ローカルマシンで実行されている各 Enterprise Application Platform インスタンスの 1 つの結果が返されます。
    2. kill process_ID, を実行してプロセスに TERM シグナルを送信します。ここで、process_ID は、上記の ps aux コマンドの 2 番目のフィールドにある数字です。
結果

これらの各代替は Enterprise Application Platform をクリーンにシャットダウンするため、データは失われません。

2.6.6. サーバー実行時に渡すスイッチと引数のリファレンス

アプリケーションサーバーの起動スクリプトは実行時に追加の引数とスイッチを受け取ります。これらのパラメーターを使用すると、standalone.xmldomain.xml、および host.xml の設定ファイルで定義されたものとは別の設定でサーバーを起動できます。これには、ソケットバインディングの代替セットや二次設定でのサーバーの起動が含まれることがあります。利用可能なこれらのパラメーターのリストには、起動時にヘルプスイッチを渡すことによってアクセスできます。

例2.7

次の例は 「スタンドアローンサーバーとして JBoss Enterprise Application Platform 6 を起動」 で説明されたサーバーの起動に似ていますが、-h スイッチまたは --help スイッチが追加されています。ヘルプスイッチの結果については、以下の表で説明されています。
[localhost bin]$ standalone.sh -h

表2.6 実行時スイッチおよび引数の表

引数またはスイッチ 説明
-b=<value> システムプロパティー jboss.bind.address を該当する値に設定します。
-b <value> システムプロパティー jboss.bind.address を該当する値に設定します。
-b<interface>=<value> システムプロパティー jboss.bind.address.<interface> を該当する値に設定します。
-D<name>[=<value>] システムプロパティーを設定します。
-h ヘルプメッセージを表示し、終了します。
--help ヘルプメッセージを表示し、終了します。
-P=<url> 該当する URL からシステムプロパティーをロードします。
-P <url> 該当する URL からシステムプロパティーをロードします。
--properties=<url> 該当する URL からシステムプロパティーをロードします。
--server-config=<config> 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
-V アプリケーションサーバーのバージョンを表示し、終了します。
-v アプリケーションサーバーのバージョンを表示し、終了します。
--version アプリケーションサーバーのバージョンを表示し、終了します。

2.7. JBoss Enterprise Application Platform 6 をサービスとして実行

2.7.1. JBoss Enterprise Application Platform 6 をオペレーティングシステムサービスとして実行

JBoss Enterprise Application Platform 6 は、サービスとして実行するよう設定できます。ユーザーはシステム実行時にドメインまたはスタンドアロンサーバー設定を使用でき、ローカルシステムからログアウトしたときにサーバーインスタンスを実行し続けることができます。

2.7.2. Red Hat Enterprise Linux でサービスとして JBoss Enterprise Application Platform をインストール

概要

以下の手順を使用して JBoss Enterprise Application Platform 6 をサービスとして Red Hat Enterprise Linux にインストールします。

前提条件

このタスクを完了するには管理者権限が必要です。

手順2.2 タスク

  1. /etc/init.d/ ディレクトリーに起動スクリプトをコピーします。

    起動スクリプトと、関連する設定ファイルは、EAP_HOME/bin/init.d/ ディレクリーに存在します。これらの各ファイルを /etc/init.d/ ディレクリーにコピーします。
    [user@host init.d]$sudo cp jboss-as-standalone.sh jboss-as.conf /etc/init.d
  2. 起動スクリプトをサービスとして追加します。

    chkconfig サービス管理コマンドを使用して、新しい jboss-as-standalone.sh サービスを自動的に起動されるサービスのリストに追加します。
    [user@host init.d]$sudo chkconfig --add jboss-as-standalone.sh
  3. スクリプトオプションを編集します。

    必要な場合は、jboss-as.conf ファイルを編集して JBoss Enterprise Application Platform と JVM の起動オプションをカスタマイズします。ファイルのコメントをガイダンスとして使用します。このファイルで、JBoss Enterprise Application Platform 6 を抽出したディレクリーを参照するよう JBOSS_HOME 変数を設定することが推奨されます。ディレクリー名の最後にスラッシュ (/) を追加しないでください。
  4. スクリプト自体を編集します。

    起動スクリプト自体を編集する必要がある場合があります。起動ファイルの名前と JBoss Enterprise Application Platform インスタンスの場所について推測が行われます。スクリプトをカスタマイズし、以下の変数に特別な注意を払います。これらの変数は、JBoss Enterprise Application Platform 6 を管理対象ドメインとして起動するためにカスタマイズする必要があります。
    • JBOSS_HOME - JBoss Enterprise Application Platform 6 が抽出される場所
    • JBOSS_USER - JBoss Enterprise Application Platform を実行できるユーザー。これは、非特権ユーザーである必要があります (スーパーユーザー特権なし)。
    • JBOSS_CONFIG - JBoss Enterprise Application Platform 6 を起動するために使用される設定ファイルの名前 (domain.xmlstandalone.xml など)
    • JBOSS_SCRIPT - JBoss Enterprise Application Platform 6 を起動するために使用されるスクリプト (domain.shstandalone.sh など)
  5. サービスを起動します。

    必要な場合は、Red Hat Enterprise Linux サービスを起動するために標準的な構文を使用して新しいサービスを起動します。
    [user@host bin]$sudo service jboss-as-standalone.sh start
結果

JBoss Enterprise Application Platform 6 は、Red Hat Enterprise Linux がデフォルトのランレベルに到達したときに自動的に起動し、オペレーティングシステムでシャットダウンルーチンが完了した時に自動的に終了します。

2.7.3. JBoss Enterprise Application Platform 6 をサービスとして Microsoft Windows にインストール

概要

このタスクでは、JBoss Enterprise Application Platform 6 をサービスとして Microsoft Windows にインストールします。

前提条件

このタスクを完了するには管理者権限が必要です。

手順2.3 タスク

  1. お使いのアーキテクチャー向けのネイティブユーティリティーパッケージをダウンロードします。

    32 ビット、64 ビット、および Itanium 64 ビットパッケージは、Red Hat カスタマーポータル (https://access.redhat.com) で入手できます。Red Hat カスタマーポータルからのソフトウェアのダウンロードに関する詳細については、『『JBoss Enterprise Application Platform 6 Installation Guide』』(JBoss Enterprise Application Platform 6 インストールガイド) (https://access.redhat.com/knowledge/docs/JBoss_Enterprise_Application_Platform/ で入手可能) を参照してください。
  2. ダウンロードしたアーカイブを展開します。

    アーカイブを新規フォルダーに展開します。
    結果: modules\native\bin\ フォルダーが作成されます。

    modules\native\bin\ フォルダーには、JBoss Enterprise Application Platform 6 をサービスとしてインストールするために必要なファイルが含まれます。これらのサービスは、Apache Commons により提供される一連のラッパースクリプトである 『Procrun』 の一部です。『Procrun』 とその構文の詳細については、http://commons.apache.org/daemon/procrun.html を参照してください。

  3. modules\sbin\prunsrv.exe 実行可能ファイルを実行します。

    prunsrv.exe install path_to_startup_script
    結果

    サービスがインストールされます。JBoss Enterprise Application Platform 6 がサービスアプレット services.msc にリストされます。

  4. サービスを管理します。

    modules\bin\prunmgr.exe 実行可能ファイルを使用してサービスを管理、追加、または削除します。以下のコマンドラインオプションがサポートされています。
    • run
    • service
    • start
    • stop
    • update
    • install
    • delete
    • pause [seconds]
    • version
    • help
    一般的な構文は以下のとおりです。
    prunmgr.exe commandservice_name
結果

コマンドラインで net service コマンドを使用するか、services.msc アプレットを使用して、Microsoft Windows Server で JBoss Enterprise Application Platform 6 を起動および停止したり、JBoss Enterprise Application Platform 6 の自動起動を管理したりできます。

2.8. サーバーの起動と停止

2.8.1. サーバーの起動と停止

サーバーは、管理 CLI または管理コンソールを使用して起動および停止できます。
スタンドアロンサーバーインスタンスを実行している場合は、管理 CLI で shutdown 操作を使用してサーバーをシャットダウンできます。管理コンソールでは同等の操作が存在しません。これはお使いのファイルシステムを自由に使用して実行中のインスタンスをシャットダウンできるためです。
監理対象ドメインを実行している場合は、管理コンソールでドメインの特定のサーバーを起動または停止できます。管理 CLI では、すべての非アクティブなサーバーを起動し、現在実行中のサーバーを停止できます。スタンドアロンサーバーインスタンスと同様に、shutdown 操作により、サーバー、ドメインコントローラー (この場合は特に)、すべてのホストコントローラー、およびサーバーインスタンスがシャットダウンされます。

2.8.2. 管理コンソールを使用したサーバーの起動

手順2.4 タスク

  1. 管理コンソールでの Server Instances への移動

    1. コンソールの右上から Runtime タブを選択します。
    2. コンソールの左側にあるメニューから Domain StatusServer Instances を選択します。
    サーバーインスタンス

    図2.1 サーバーインスタンス

  2. サーバーの選択

    Server Instances のリストから、起動するサーバーを選択します。実行されているサーバーはチェックマークで示されます。
  3. Start ボタンをクリックします。

    サーバーリスト上部にある Start ボタンをクリックして、確認ダイアログボックスを開きます。Confirm ボタンをクリックしてサーバーを起動します。
    サーバーの変更の確認

    図2.2 サーバーの変更の確認

結果

選択されたサーバーは起動され、実行されています。

起動されたサーバー

図2.3 起動されたサーバー

2.8.3. 管理コンソールを使用したサーバーの停止

手順2.5 タスク

  1. 管理コンソールの Server Instances に移動します。

    1. コンソールの右上から Runtime タブを選択します。
    2. コンソールの左側にあるメニューから Domain StatusServer Instances を選択します。
    サーバーインスタンス

    図2.4 サーバーインスタンス

  2. サーバーの選択

    Server Instances のリストから、停止するサーバーを選択します。実行されているサーバーはチェックマークで示されます。
  3. Stop ボタンをクリックします。

    サーバーリスト上部にある Stop ボタンをクリックして、確認ダイアログボックスを開きます。Confirm ボタンをクリックしてサーバーを起動します。
    サーバーの変更の確認

    図2.5 サーバーの変更の確認

結果

選択されたサーバーが停止します。

停止されたサーバー

図2.6 停止されたサーバー

2.9. ファイルシステムパス

2.9.1. ファイルシステムパス

JBoss Enterprise Application Platform 6 では、ファイルシステムパスに論理名を使用します。domain.xmlhost.xml、および standalone.xml の設定には、パスを宣言できるセクションが含まれます。設定の他のセクションは、各インスタンスの絶対パスを宣言せず論理名を使用することにより、これらのパスを参照できます。これにより、特定のホスト設定をユニバーサルな論理名に解決できるため、設定や管理がしやすくなります。
たとえば、ロギングサブシステム設定には、サーバーのlog ディレクトリーを参照する jboss.server.log.dir パスの参照が含まれます。

例2.8 ロギングディレクトリーの相対パス例

<file relative-to="jboss.server.log.dir" path="server.log"/>

JBoss Enterprise Application Platform 6 では、複数の標準的なパスが自動的に提供されるため、ユーザーが設定ファイルでこれらのパスを設定する必要はありません。

表2.7 標準的なパス

説明
jboss.home JBoss EAP 6 ディストリビューションのルートディレクトリー。
user.home ユーザーホームディレクトリー。
user.dir ユーザーのカレントワーキングディレクトリ。
java.home Java インストールディレクトリー。
jboss.server.base.dir 各サーバーインスタンスのルートディレクトリー。
jboss.server.data.dir サーバーが永続データファイルストレージに使用するディレクトリー。
jboss.server.log.dir サーバーがファイルストレージに使用するディレクトリー。
jboss.server.tmp.dir サーバーが一時ファイルストレージに使用するディレクトリー。
jboss.domain.servers.dir ホストコントロールが管理対象ドメインの各サーバーインスタンスに対して作業領域を作成するディレクトリー。
ユーザーは、path 要素を設定ファイルに追加することにより、独自のパスを追加したり、上記の最初の 5 つを除くすべてをオーバーライドしたりできます。次の例は、各サーバーインスタンスのルートディレクトリーに対する新しい相対パス宣言を示しています。

例2.9 相対パスの形式

<path name="examplename" path="example/path" relative-to="jboss.server.data.dir"/>

パス宣言の構造では以下の属性が使用されます。

表2.8 パス属性

属性 説明
name パスの名前。
path 実際のファイルシステムパス。relative-to 属性が指定されない限り、絶対パスとして処理され、値はそのパスの相対パスとして処理されます。
relative-to 以前に指定された別のパスの名前を示すオプション属性、またはシステムにより提供される標準的ないずれかのパス。
domain.xml 設定ファイルの path 要素には、name 属性のみが必要です。以下の例のとおり、実際のファイルシステムパスを示す情報を含める必要はありません。

例2.10 ドメインパスの例

<path name="example"/>

この設定は、domain.xml 設定の他の部分が参照できる example という名前のパスがあることを宣言します。example で宣言された実際のファイルシステムの場所は、ドメイングループに参加しているホストインスタンスの各 host.xml 設定ファイルに固有です。この方法が使用された場合は、実際のファイルシステムパスを指定する各マシンの host.xml にパス要素が含まれる必要があります。

例2.11 ホストパスの例

<path name="example" path="path/to/example" />

standalone.xml 内の path 要素には、実際のファイルシステムパスの指定を含める必要があります。

2.10. ファイルの履歴設定

2.10.1. ファイルの履歴設定

アプリケーションサーバーの設定ファイルには、standalone.xmlインスタンス、domain.xmlhost.xml ファイルが含まれます。これらのファイルは直接編集することで変更できますが、アプリケーションサーバーモデルを管理 CLI や管理コンソールといった、利用可能な管理オペレーションを使い設定する方法を推奨しています。
サーバーインスタンスの保守、管理をしやすくするには、起動時にアプリケーションサーバーが元の設定ファイルにタイムスタンプをつけたバージョンを作成してください。管理オペレーションで加えられた追加設定は、自動的にバックアップされた元ファイルと、参照、ロールバックできるよう確保された作業用インスタンスの形となります。このアーカイブ機能はサーバー設定の保存、ロード、削除、スナップショットなどにまで拡張され、シナリオの取り消しやロールバックが可能となります。

2.10.2. サーバーを以前の設定で起動

以下の例は、standalone.xml を使用してスタンドアロンサーバーの以前の設定でアプリケーションサーバーを起動する方法を示しています。同じコンセプトは、domain.xmlhost.xml それぞれを使用した監理対象ドメインに適用されます。
この例では、管理操作によってサーバーモデルが変更される場合にアプリケーションサーバーにより自動的に保存される以前の設定が呼び出されます。
  1. 開始するバックアップバージョンを特定します。この例では、正常な起動後の最初の変更の前にサーバーモデルのインスタンスが呼び出されます。
    EAP_HOME/configuration/standalone_xml_history/current/standalone.v1.xml 
  2. jboss.server.config.dir 下で相対ファイル名を渡すことによってバックアップモデルのこのインスタンスでサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml 
結果

アプリケーションサーバーが、選択された設定で起動されます。

2.10.3. 管理 CLI を使用した設定スナップショットの保存

スナップショットは、現在のサーバーインスタンスのポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xmlインスタンスを使用しますが、同じプロセスは domain.xml モデルと host.xml モデルに適用されます。
タスク

  • スナップショットの保存

    take-snapshot 操作を実行して、現在のサーバーインスタンスのコピーを取得します。
    [standalone@localhost:9999 /] :take-snapshot
    {
        "outcome" => "success",
        "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
    }
    
    
結果

現在のサーバーインスタンスのスナップショットが保存されます。

2.10.4. 設定スナップショットのロード

スナップショットは、現在のサーバーインスタンスのポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。スナップショットのロードのプロセスは、「サーバーを以前の設定で起動」で使用された方法に似ており、スナップショットを作成、リスト、および削除するために使用される管理 CLI インターフェースではなくコマンドラインから実行します。
次の例では standalone.xmlインスタンスを使用しますが、同じプロセスは domain.xml モデルと host.xml モデルに適用されます。
タスク

  1. ロードするスナップショットを識別します。この例では、スナップショットディレクトリーから以下のファイルが呼び出されます。スナップショットファイルのデフォルトのパスは以下のとおりです。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    スナップショットは相対パスにより表されます。たとえば、上記の例は次のように記述できます。
    jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
  2. ファイル名を渡して、選択したスナップショットインスタンスでサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
結果

サーバーは、選択したスナップショットプロファイルで再起動されます。

2.10.5. 管理 CLI を使用した設定スナップショットの削除

スナップショットは、現在のサーバーインスタンスのポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xmlインスタンスを使用しますが、同じプロセスは domain.xml モデルと host.xml モデルに適用されます。
タスク

  1. スナップショットの削除

    ロードするスナップショットを指定します。この例では、スナップショットディレクトリーから以下のファイルが削除されます。
                         jboss.domain.config.dir/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml 
  2. スナップショットの削除

    :delete-snapshot コマンドを実行して、特定のスナップショットを削除します。
    [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
                {"outcome" => "success"}
    
結果

スナップショットが削除されます。

2.10.6. 管理 CLI を使用したすべての設定スナップショットのリスト

スナップショットは、現在のサーバーインスタンスのポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xmlインスタンスを使用しますが、同じプロセスは domain.xml モデルと host.xml モデルに適用されます。

手順2.6 タスク

  • すべてのスナップショットのリスト

    :list-snapshotsコマンドを実行して、保存されたすべてのスナップショットをリストします。
    [standalone@localhost:9999 /] :list-snapshots
    {
        "outcome" => "success",
        "result" => {
            "directory" => "/home/hostname/EAP_Home/standalone/configuration/standalone_xml_history/snapshot",
            "names" => [
                "20110818-133719699standalone.xml",
                "20110809-141225039standalone.xml",
                "20110802-152010683standalone.xml",
                "20110808-161118457standalone.xml",
                "20110912-151949212standalone.xml",
                "20110804-162951670standalone.xml"
            ]
        }
    }
    
結果

スナップショットがリストされます。

第3章 管理インターフェース

3.1. 管理コンソールと管理 CLI について

JBoss Enterprise Application Platform 6 では、すべてのサーバーインスタンスと設定が、XML ファイルの編集ではなく管理インターフェースにより管理されます。設定 XML ファイルは引き続き編集できますが、管理インターフェースによる管理は、サーバーインスタンスの永続的な管理に対して追加の検証機能および上級機能を提供します。サーバーインスタンスの実行中に XML 設定ファイルに加えられた変更はサーバーモデルによって上書きされ、追加された XML コメントもすべて削除されます。サーバーインスタンスの実行中は管理インターフェースのみを使用して設定ファイルを変更する必要があります。
Web ブラウザーでグラフィカルユーザーインターフェースを使用してサーバーを管理するには、管理コンソールを使用します。
コマンドラインインターフェースを使用してサーバーを管理するには、管理 CLI を使用します。

3.2. 管理コンソール

3.2.1. 管理コンソール

管理コンソールは Enterprise Application Platform の Web ベースの管理ツールです。
管理コンソールを使いサーバーの開始、停止、アプリケーションのデプロイ、アンデプロイ、システム設定の調整、サーバー設定の変更の永続化を行います。管理コンソールにも、管理権限タスクでの実行機能や、変更後サーバーインスタンスを再起動、再ロードする必要がある場合はその場で通知を出す機能があります。
管理ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから一元管理することができます。

3.2.2. 管理コンソールへログイン

前提条件

  • JBoss Enterprise Application Platform 6 が稼働している必要があります。

手順3.1 タスク

  1. 管理コンソールのスタートページに移動

    Web ブラウザーで管理コンソールに移動します。デフォルトの場所は http://localhost:9990/console/ です。ポート 9990 は管理コンソールのソケットバインディングとして事前定義されています。
  2. 管理コンソールへログイン

    以前作成したアカウントのユーザー名とパスワードを入力し、管理コンソールのログイン画面にログインします。
    管理コンソールのログイン画面。

    図3.1 管理コンソールのログイン画面

結果

ログインすると、管理コンソールの最初のページが表示されます。
管理対象ドメイン
スタンドアロンサーバー

3.2.3. 管理コンソールの言語の変更

Web ベースの管理コンソールの言語設定では、デフォルトで英語が使用されます。英語の代わりに次のいずれかの言語を使用することを選択できます。

サポート言語

  • ドイツ語 (de)
  • 簡体中国語 (zh-Hans)
  • ブラジルポルトガル語 (pt-BR)
  • フランス語 (fr)
  • スペイン語 (es)
  • 日本語 (ja)

手順3.2 タスク

  1. 管理コンソールにログインします。

    Web ベースの管理コンソールにログインします。
  2. Settings ダイアログを開きます。

    画面の右下付近に Settings ラベルがあります。これをクリックして管理コンソールの設定を開きます。
  3. 必要な言語を選択します。

    Locale 選択ボックスから必要な言語を選択します。次に、Save を選択します。確認ボックスで、アプリケーションをリロードする必要があることが示されます。Confirm をクリックします。新しいロケールを使用するために Web ブラウザを更新します。

3.2.4. 管理コンソールを使用したサーバーの設定

手順3.3 タスク

  1. 管理コンソールでサーバーの Server Configuration パネルに移動します。

    1. コンソールの右上から Server タブを選択します。
    2. コンソールの左側にある Server Configurations メニュー項目を展開し、リストから該当するサーバーを選択します。
    サーバー設定

    図3.2 サーバー設定

  2. サーバー設定の編集

    1. サーバーリストの下にある Edit ボタンをクリックします。
    2. 設定属性の変更を行います。
    3. サーバーリストの下にある Save ボタンをクリックします。
結果

サーバー設定が変更され、サーバーの次回再起動時に反映されます。

3.2.5. 管理コンソールでのデプロイメントの追加

手順3.4 タスク

  1. 管理コンソールの Manage Deployments パネルに移動します。

    1. コンソールの右上から Runtime タブを選択します。
    2. 管理ドメインまたはスタンドアロンサーバーに対し、コンソールの左側にあるメニューから DeploymentsManage Deployments オプションを選択します。
    Manage Deployments パネルが表示されます。
    ドメインデプロイメントの管理

    図3.3 ドメインデプロイメントの管理

  2. デプロイメントコンテンツの追加

    Deployments パネルの右上の Add Content ボタンを選択します。Upload ダイアログボックスが表示されます。
  3. デプロイするファイルの選択

    ダイアログボックスで、Choose File ボタンを選択します。デプロイするファイルを参照し、アップロードするために選択します。ファイルが選択されたら、Next ボタンを選択して 作業を続行します。
    デプロイメント選択

    図3.4 デプロイメント選択

  4. デプロイメント名の確認

    Upload ダイアログボックスに表示されるデプロイメント名とランタイム名を確認します。名前を確認したら、Save ボタンを選択してファイルをアップロードします。
    デプロイメント名の確認

    図3.5 デプロイメント名の確認

結果

選択したコンテンツがサーバーにアップロードされ、デプロイメント可能になります。

管理ドメインのアップロードされたデプロイメント

図3.6 管理ドメインのアップロードされたデプロイメント

スタンドアロンサーバーインスタンスのアップロードされたデプロイメント

図3.7 スタンドアロンサーバーインスタンスのアップロードされたデプロイメント

3.2.6. 管理コンソールでの新しいサーバーの作成

手順3.5 タスク

  1. 管理コンソールの Server Configuration パネルに移動します。

    1. コンソールの右上から Hosts タブを選択します。
    2. コンソールの左側にある Server Configurations メニュー項目を展開し、リストから既存のサーバーを選択します。
    選択したサーバーの Server Configuration パネルが表示されます。
    サーバー設定

    図3.8 サーバー設定

  2. 新しい設定の作成

    1. Server Configuration パネルの上部にある New Server Config ボタンを選択します。
    2. Create Server Configuration ダイアログで基本的なサーバー設定を編集します。
    3. Save ボタンを選択して、新しいサーバー設定を保存します。
    新しい設定の作成

    図3.9 新しい設定の作成

結果

新しいサーバーが作成され、Server Configurations リストに表示されます。

3.2.7. 管理コンソールを使用したデフォルトログレベルの変更

手順3.6 タスク

  1. 管理コンソールの Logging パネルに移動します。

    1. 管理ドメインを使用している場合は、コンソールの右上の Profiles タブを選択し、次にコンソールの左側にあるドロップダウンリストから該当するプロファイルを選択します。
    2. 管理ドメインまたはスタンドアロンサーバーに対し、コンソールの左側にあるメニューより CoreLogging と選択します。
    3. コンソール上部の Log Categories タグをクリックします。
    ロギングパネル

    図3.10 ロギングパネル

  2. ロガーの詳細の編集

    Log Categories テーブル内のいずれかのエントリの詳細を編集します。
    1. Log Categories テーブル内のエントリを選択し、下の Details セクションの Edit ボタンを押します。
    2. Log Level ドロップダウンボックスでカテゴリーのログレベルを設定します。設定したら、Save ボタンを押します。
結果

該当するカテゴリーのログレベルが更新されます。

3.2.8. 管理コンソールで新規サーバーグループを作成

手順3.7 タスク

  1. Server Groups のビューに移動します。

    右上端の Profiles タブを選択します。
  2. 左側の欄の Server Groups メニューにある Group Configurations タブを選択します。
    Server Groups ビュー

    図3.11 Server Groups ビュー

  3. サーバーグループの追加

    Add ボタンをクリックし新規サーバーグループを追加します。
  4. サーバーグループの設定

    1. サーバーグループ名を入力します。
    2. サーバーグループを追加したいプロファイルを選択します。
    3. サーバーグループを追加したいソケットバインディングを選択します。
    4. Save ボタンを押し新しく作成したグループを保存します。
    Create Server Group ダイアログ

    図3.12 Create Server Group ダイアログ

結果

この新規サーバーグループが管理コンソールで表示されるようになります。

3.3. 管理 CLI

3.3.1. 管理コマンドラインインターフェース (CLI)

管理コマンドラインインターフェース (CLI) は、JBoss Enterprise Application Platform 6 のコマンドライン管理ツールです。
管理 CLI を使用して、サーバーの起動および停止、アプリケーションのデプロイおよびデプロイ解除、システム設定の調整、および他の管理タスクの実行を行います。操作はバッチモードで実行でき、複数のタスクをグループとして実行できます。
管理ドメインにより、同じドメイン内のアプリケーションサーバーをドメインコントローラーの管理コンソールを使い一元管理することができます。

3.3.2. Management CLI の起動

手順3.8 タスク

    • Linux での CLI の起動

      コマンドラインで以下のコマンドを入力して、EAP_HOME/bin/jboss-cli.sh ファイルを実行します。
      $ EAP_HOME/bin/jboss-cli.sh
    • Windows での CLI の起動

      ダブルクリックするか、コマンドラインで以下のコマンドを入力して、EAP_HOME\bin\jboss-cli.bat ファイルを実行します。
      C:\>EAP_HOME\bin\jboss-cli.bat

3.3.3. 管理 CLI の終了

手順3.9 タスク

  • quit コマンドの実行

    管理 CLI で、quit コマンドを入力します。
    [domain@localhost:9999 /] quit
    Closed connection to localhost:9999

3.3.4. 管理 CLI を使用した管理対象サーバーインスタンスへの接続

手順3.10 タスク

  • connect コマンドを実行します。

    管理 CLI で、connect コマンドを入力します。
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    • または、Linux システムで管理 CLI を起動するときに管理対象サーバーに接続するために、--connect パラメーターを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect
    • --connect パラメーターは、ホストとサーバーのポートを指定するために使用できます。ポートの値が 9999 であるアドレス 192.168.0.1 に接続するには、次のコマンドが適用されます。
      $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

3.3.5. 管理 CLI でのヘルプの使用

概要

管理 CLI には、一般的なオプションと状況依存オプションから構成されるヘルプダイアログが組み込まれてます。運用状況に依存するヘルプコマンドでは、スタンドアロンまたはドメインコントローラーへの接続を確立する必要があります。接続が確立されない限り、これらのコマンドはリストに表示されません。

手順3.11 タスク

  1. help コマンドの実行

    管理 CLI で、help コマンドを入力します。
    [standalone@localhost:9999 /] help
  2. 状況依存ヘルプの使用

    管理 CLI で、help -commands 拡張コマンドを入力します。
    [standalone@localhost:9999 /] help --commands
  3. 特定のコマンドの詳細については、'--help' を引数として help コマンドを実行してください。
    [standalone@localhost:9999 /]  deploy --help
結果

CLI ヘルプ情報が表示されます。

3.3.6. バッチモードでの管理 CLI の使用

手順3.12 タスク

バッチ処理により、複数の操作をシーケンスでグループ化し、ユニットとして一緒に実行できます。シーケンス内のいずれかの操作要求が失敗したら、操作のグループ全体がロールバックされます。
  1. バッチモードの開始

    batch コマンドを使用してバッチモードを開始します。
    [standalone@localhost:9999 /] batch
    [standalone@localhost:9999 / #]
    バッチモードは、プロンプトでハッシュ記号 (#) で示されます。
  2. バッチへの操作要求の追加

    バッチモードが開始されたら、操作要求を通常どおり入力します。操作要求は、入力された順序でバッチに追加されます。
    操作要求のフォーマット化の詳細については、「管理 CLI での操作とコマンドの使用」 を参照してください。
  3. バッチの実行

    操作要求のシーケンス全体が入力されたら、run-batch コマンドを使用してバッチを実行します。
    [standalone@localhost:9999 / #] run-batch
    The batch executed successfully.
結果

操作要求の入力されたシーケンスはバッチとして完了します。

3.3.7. 管理 CLI での操作とコマンドの使用

手順3.13 タスク

  1. 操作要求の構築

    操作要求では、管理モデルとの低レベルの対話が可能です。この場合、サーバー設定を制御された方法で編集できます。操作要求は、以下の 3 つの部分から構成されます。
    • アドレス (スラッシュ (/) の接頭辞を指定)。
    • 操作名 (コロン (:) の接頭辞を指定)。
    • パラメーターのオプションセット (丸かっこ (()) で囲む)。
    1. アドレスの決定

      設定はアドレス指定可能なリソースの階層ツリーとして表されます。各リソースノードは、異なる操作セットを提供します。アドレスは、操作を実行するリソースノードを指定します。アドレスでは以下の構文を使用します。
      /node-type=node-name
      • node-type は、リソースノードタイプです。これは、設定 XML の要素名に対してマッピングされます。
      • これは、 node-name はリソースノード名です。これは、設定 XML の要素の name 属性に対してマッピングされます。
      • スラッシュ (/) を使用してリソースツリーの各レベルを区切ります。
      設定 XML ファイルを参照して必要なアドレスを決定します。EAP_HOME/standalone/configuration/standalone.xml ファイルは、スタンドアロンサーバーの設定を保持し、EAP_HOME/domain/configuration/domain.xml ファイルと EAP_HOME/domain/configuration/host.xml ファイルは管理対象ドメインの設定を保持します。

      例3.1 操作アドレスの例

      ロギングサブシステムで操作を実行するには、操作要求の以下のアドレスを使用します。
      /subsystem=logging
      Java データソースに対して操作を実行するには、操作要求の以下のアドレスを使用します。
      /subsystem=datasources/data-source=java
    2. 操作の決定

      リソースノードの各タイプに応じて操作は異なります。操作では以下の構文を使用します。
      :operation-name
      • operation-name は、要求する操作の名前です。
      利用可能な操作をリストするために、スタンドアロンサーバーの任意のリソースアドレスで read-operation-names 操作を使用します。

      例3.2 利用可能な操作

      ロギングサブシステムのすべての利用可能な操作をリストするために、スタンドアロンサーバーの以下の要求を入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "change-root-log-level",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove-root-logger",
              "set-root-logger",
              "write-attribute"
          ],
          "compensating-operation" => undefined
      }
    3. パラメーターの決定

      各操作では異なるパラメーターが必要な場合があります。
      パラメーターは以下の構文を使用します。
      (parameter-name=parameter-value)
      • parameter-name は、パラメーターの名前です。
      • parameter-value は、パラメーターの値です。
      • 複数のパラメーターは、カンマ (,) で区切られます。
      必要なパラメーターを決定するには、リソースノードで操作名をパラメーターとして渡し、read-operation-description コマンドを実行します。詳細については、例3.3「操作パラメーターの決定」 を参照してください。

      例3.3 操作パラメーターの決定

      ロギングサブシステムで change-root-log-level 操作の必須パラメーターを決定するには、以下のように read-operation-description コマンドを入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=change-root-log-level)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "change-root-log-level",
              "description" => "Change the root logger level.",
              "request-properties" => {"level" => {
                  "type" => STRING,
                  "description" => "The log level specifying which message levels will be logged by this logger. 
                                   Message levels lower than this value will be discarded.",
                  "required" => true
              }}
          },
          "compensating-operation" => undefined
      }
  2. 完全操作要求の入力

    アドレス、操作、およびパラメーターが決定されたら、完全操作要求を入力します。

    例3.4 操作要求の例

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
結果

管理インターフェースは、サーバー設定の操作要求を実行します。

3.3.8. 管理 CLI コマンドのリファレンス

概要

トピック「管理 CLI でのヘルプの使用」では、一般オプションと状況依存オプションがあるヘルプダイアログが含まれる、管理 CLI ヘルプ機能のアクセス方法について説明しています。ヘルプコマンドは、操作コンテキストに依存し、スタンドアロンまたはドメインコントローラーへ確立された接続を必要とします。接続が確立されない限り、これらのコマンドはリストに表示されません。

表3.1

コマンド 説明
batch 新しいバッチを作成してバッチモードを開始するか、既存の保留中のバッチに応じて、バッチを再びアクティベートします。保留中のバッチがない場合は、引数なしで呼び出されたこのコマンドによって新しいバッチが開始されます。名前がない保留中のバッチがある場合は、このコマンドによってそのバッチが再びアクティベートされます。名前がある保留中のバッチがある場合は、保留中のバッチの名前を引数にしてこのコマンドを実行することにより、これらのバッチをアクティベートできます。
cd 現在のノードパスを引数に変更します。現在のノードパスはアドレス部分を含まない操作要求のアドレスとして使用されます。操作要求にアドレスが含まれる場合、そのアドレスは現在のノードパスに対して相対的であると見なされます。現在のノードパスは node-type で終わることがあります。その場合は、logging:read-resource などの node-name を指定すれば操作を実行できます。
clear 画面を消去します。
command 新しいタイプコマンドを追加し、既存の汎用タイプコマンドを削除およびリストできます。汎用タイプコマンドは、特定のノードタイプに割り当てられたコマンドであり、そのタイプのインスタンス向けの操作を実行可能にします。また、既存インスタンスのタイプにより公開された任意のプロパティーを変更することもできます。
connect 指定されたホストおよびポートのコントローラに接続します。
connection-factory 接続ファクトリーを定義します。
data-source データソースサブシステムで JDBC データソース設定を管理します。
deploy ファイルパスで指定されたアプリケーションをデプロイするか、リポジトリで無効な既存のアプリケーションを有効にします。引数なしで実行された場合は、このコマンドにより、既存のすべてのデプロイメントがリストされます。
help ヘルプメッセージを表示します。該当するコマンドの状況依存の結果を提供するには、--commands 引数とともに使用します。
history メモリー内の CLI コマンド履歴を表示し、履歴拡張が有効または無効であるかを表示します。必要に応じて履歴拡張をクリア、無効、および有効にするには、引数とともに使用します。
jms-queue メッセージングサブシステムで JMS キューを定義します。
jms-topic メッセージングサブシステムで JMS トピックを定義します。
ls ノードパスの内容をリストします。デフォルトでは、ターミナルの全体の幅を使用して結果が列で出力されます。-l スイッチを使用すると、1 行あたり 1 つの名前で結果が出力されます。
pwd 現在動作しているノードの完全ノードパスを出力します。
quit コマンドラインインターフェースを終了します。
read-attribute 値を出力し、引数によっては管理対象リソースの属性の説明も出力します。
read-operation 指定された操作の説明を表示します。指定された操作がない場合は利用可能なすべての操作をリストします。
undeploy 目的のアプリケーションの名前で実行された場合にアプリケーションをアンデプロイします。リポジトリからアプリケーションを削除するには引数とともに使用します。アプリケーションを指定せずに実行すると、既存のすべてのデプロイメントをリストします。
version アプリケーションサーバーのバージョンと環境情報を出力します。
xa-data-source データソースサブシステムで JDBC XA データソース設定を管理します。

3.3.9. 管理 CLI 操作のリファレンス

Management CLI の操作の公開

Management CLI の操作は、トピック 「管理 CLI を使用した操作名の表示」 で解説している read-operation-names を使用すると公開できます。また、操作の説明は、トピック 「管理 CLI を使用した操作説明の表示」 で解説している read-operation-descriptions 操作を使用すると公開できます。

表3.2 Management CLI の操作

操作名 説明
add-namespace namespaces 属性のマップに名前空間プレフィックスマッピングを追加します。
add-schema-location schema-locations 属性のマップにスキーマロケーションマッピングを追加します。
delete-snapshot snapshots ディレクトリからサーバー設定のスナップショットを削除します。
full-replace-deployment 以前にアップロードされたデプロイメントコンテンツを使用可能なコンテンツの一覧に追加して、ランタイムの同名の既存コンテンツを置き換え、その置き換えられたコンテンツを使用可能なコンテンツの一覧から削除します。詳細はリンク先を参照してください。
list-snapshots snapshots ディレクトリに保存されているサーバー設定のスナップショットを一覧表示します。
read-attribute 選択したリソースの属性値を表示します。
read-children-names 指定タイプの選択したリソース配下にあるすべての子リソースの名前を表示します。
read-children-resources 指定のタイプであるすべての子リソースに関する情報を表示します。
read-children-types 選択したリソースの配下にあるすべての子リソースのタイプ名を表示します。
read-config-as-xml 現在の設定を読み込み、XML 形式で表示します。
read-operation-description 特定のリソースに対する操作の詳細を表示します。
read-operation-names 特定のリソースに対する全操作の名前を表示します。
read-resource モデルリソースの属性値および任意の子リソースの基本情報もしくは詳細情報を表示します。
read-resource-description リソースの属性、子リソースのタイプ、および操作についての詳細を表示します。
reload 全サービスをシャットダウンして再起動することにより、サーバーを再ロードします。
remove-namespace namespaces 属性マップから名前空間プレフィックスマッピングを削除します。
remove-schema-location schema-locations 属性マップからスキーマロケーションマッピングを削除します。
replace-deployment ランタイムの既存コンテンツを新規コンテンツに置き換えます。新規コンテンツはデプロイメントコンテンツリポジトリに事前にアップロードしておく必要があります。
resolve-expression 式を、式へ解析可能な入力または文字列として許可し、ローカルのシステムプロパティーおよび環境変数に対して解決する操作です。
resolve-internet-address インターフェース解決基準のセットを取得し、基準に一致するローカルマシンで IP アドレスを見つけます。一致する IP アドレスがない場合は失敗します。
server-set-restart-required 再起動が必要なモードにサーバーを設定します。
shutdown System.exit(0) の呼び出しにより、サーバーをシャットダウンします。
start-servers 現在実行されていないすべての設定済みサーバーを管理対象ドメインで起動します。
stop-servers 管理対象ドメインで現在実行しているすべてのサーバーを停止します。
take-snapshot サーバー設定のスナップショットを作成し、snapshots ディレクトリに保存します。
upload-deployment-bytes 含まれるバイト配列のデプロイメントコンテンツは、デプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツをランタイムへデプロイする必要があるとは指定しない点に注意してください。
upload-deployment-stream 含まれる入力ストリームインデックスで利用可能なデプロイメントコンテンツは、デプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツがランタイムにデプロイされる必要があることは指定しない点に注意してください。
upload-deployment-url 含まれる URL で利用可能なデプロイメントコンテンツはデプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツがランタイムにデプロイされる必要があることは指定しない点に注意してください。
validate-address 操作のアドレスを検証します。
write-attribute 選択したリソースの属性値を設定します。

3.4. 管理 CLI の操作

3.4.1. 管理 CLI によるリソースの属性の表示

概要

read-attribute オペレーションは、選択された属性の現在のランタイム値を読み取りするために使用されるグローバルオペレーションです。デフォルトの値や非定義の値を無視し、ユーザーによって設定された値のみを表示することが可能です。要求プロパティーには次のパラメーターが含まれます。

要求プロパティー

name
選択されたリソース下で値を取得する属性の名前。
include-defaults
false を設定すると、デフォルト値を無視し、ユーザーによって設定された属性のみを表示するようオペレーション結果を制限できるブール変数パラメーター。

手順3.14 タスク

  • read-attribute オペレーションの実行

    管理 CLI より read-attribute を使用してリソース属性の値を表示します。オペレーション要求の詳細は 「管理 CLI での操作とコマンドの使用」 を参照してください。
    [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)
read-attribute オペレーションの利点は、特定属性の現在のランタイム値を表示できることです。read-resource オペレーションでも同様の結果を得ることができますが、include-runtime 要求プロパティーを追加した場合のみ可能で、そのノードに対して使用できる全リソース一覧の一部のみを表示することができます。次の例が示すように、read-attribute オペレーションは細粒度の属性クエリを対象としています。

例3.5 read-attribute オペレーションを実行してパブリックインターフェース IP を表示する

公開したい属性の名前を知っている場合は、read-attribute を使用して現在のランタイムの厳密値を返します。
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}

resolved-address 属性はランタイム値であるため、標準的な read-resource オペレーションの結果には表示されません。
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}

resolved-address や他のランタイム値を表示するには、include-runtime 要求プロパティーを使用する必要があります。
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}

結果

現在のランタイム属性値が表示されます。

3.4.2. 管理 CLI でのアクティブユーザーの表示

概要

whoami の操作は現在アクティブなユーザーの属性を識別するために使用されるグローバルな操作です。この操作はユーザー名の ID と割り当てられたレルムを公開します。whoami の操作は、管理者が複数のレルムで複数のユーザーを管理する場合や、複数のターミナルセッションやユーザーアカウントを持つドメインインスタンス全体でアクティブユーザーを追跡する場合に便利です。

手順3.15 タスク

  • whoami の実行

    管理 CLI より whoami を使用し、アクティブユーザーのアカウントを表示します。
    [standalone@localhost:9999 /] :whoami
    次の例はスタンドアロンサーバーで whoami を使用し、アクティブユーザーは username ManagementRealm レルムが割り当てられていることを表しています。

    例3.6 スタンドアロンインスタンスでの whoami の使用

    [standalone@localhost:9999 /]<command>:whoami</command>
    {
        "outcome" => "success",
        "result" => {"identity" => {
            "username" => "username",
            "realm" => "ManagementRealm"
        }}
    }
    
    
結果

現在のアクティブユーザーのアカウントが表示されます。

3.4.3. 管理 CLI でのシステムおよびサーバー情報の表示

手順3.16 タスク

  • version コマンドの実行

    管理 CLI で、version コマンドを入力します。
    [domain@localhost:9999 /] version
結果

アプリケーションサーバーバージョンと環境情報が表示されます。

3.4.4. 管理 CLI を使用した操作説明の表示

手順3.17 タスク

  • read-operation-description 操作の実行

    管理 CLI で、read-operation-description を使用して、操作に関する情報を表示します。操作ではキーと値のペアの形式でパラメーターを追加して、表示する操作を示す必要があります。操作結果の詳細については、「管理 CLI での操作とコマンドの使用」 を参照してください。
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

例3.7 list-snapshots 操作の説明の表示

次の例は、list-snapshots 操作を説明する方法を示しています。
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored"
                },
                "names" => {
                    "type" => LIST,
                    "value-type" => STRING,
                    "description" => "The names of the snapshots within the snapshots directory"
                }
            }
        },
        "read-only" => false
    }
}
結果

選択した操作に関する説明が表示されます。

3.4.5. 管理 CLI を使用した操作名の表示

手順3.18 タスク

  • read-operation-names の実行

    管理 CLI より read-operation-names 操作を使用して利用可能な操作の名前を表示します。操作要求の詳細については、トピック「管理 CLI での操作とコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-operation-names

例3.8 管理 CLI を使用した操作名の表示

次の例は、read-operation-names 操作を説明する方法を示しています。
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "shutdown",
        "take-snapshot",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "write-attribute"
    ]
}
結果

利用可能な操作名が表示されます。

3.4.6. 管理 CLI を使用した利用可能なリソースの表示

概要

read-resource 操作は、リソース値を読み取るために使用されるグローバル操作です。これは、現在のノードまたは子ノードのリソースに関する基本的、または完全な情報を捜査結果の範囲を拡大または制限するさまざまな要求プロパティーとともに公開するために使用できます。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

recursive
子リソースに関する完全な情報を再帰的に含めるかどうか。
recursive-depth
子リソースに関する情報を含める必要がある深度。
proxies
再帰的なクエリーにリモートリソースを含めるかどうか (たとえば、ドメインコントローラーのクエリーにスレーブホストコントローラーからのホストレベルリソースを含めるかどうか)。
include-runtime
応答に、永続的な設定ではない属性値などのランタイム属性を含めるかどうか。この要求プロパティーは、デフォルトで false に設定されます。
include-defaults
デフォルト属性の読み取りを有効または無効にするブール値要求プロパティー。falseに設定された場合は、ユーザが設定した属性のみが返され、未定義のままの属性は無視されます。

手順3.19 タスク

  1. read-resource 操作の実行

    管理 CLI で、read-resource 操作を使用して利用可能なリソースを表示します。
    [standalone@localhost:9999 /]:read-resource
    以下の例は、スタンドアロンサーバーインスタンスで read-resource 操作を使用して一般的なリソース情報を公開する方法を示しています。結果は standalone.xml 設定ファイルに類似し、サーバーインスタンス向けにインストールまたは設定されたシステムリソース、拡張機能、インターフェース、およびサブシステムを表示します。これらは、さらに直接問い合わせることができます。

    例3.9 ルートレベルでの read-resource 操作の使用

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "deployment" => undefined,
            "management-major-version" => 1,
            "management-minor-version" => 2,
            "name" => "hostname",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.0.0.GA",
            "profile-name" => undefined,
            "release-codename" => "Steropes",
            "release-version" => "7.1.2.Final-redhat-1",
            "schema-locations" => [],
            "system-property" => undefined,
            "core-service" => {
                "management" => undefined,
                "service-container" => undefined,
                "server-environment" => undefined,
                "platform-mbean" => undefined
            },
            "extension" => {
                "org.jboss.as.clustering.infinispan" => undefined,
                "org.jboss.as.configadmin" => undefined,
                "org.jboss.as.connector" => undefined,
                "org.jboss.as.deployment-scanner" => undefined,
                "org.jboss.as.ee" => undefined,
                "org.jboss.as.ejb3" => undefined,
                "org.jboss.as.jaxrs" => undefined,
                "org.jboss.as.jdr" => undefined,
                "org.jboss.as.jmx" => undefined,
                "org.jboss.as.jpa" => undefined,
                "org.jboss.as.logging" => undefined,
                "org.jboss.as.mail" => undefined,
                "org.jboss.as.naming" => undefined,
                "org.jboss.as.osgi" => undefined,
                "org.jboss.as.pojo" => undefined,
                "org.jboss.as.remoting" => undefined,
                "org.jboss.as.sar" => undefined,
                "org.jboss.as.security" => undefined,
                "org.jboss.as.threads" => undefined,
                "org.jboss.as.transactions" => undefined,
                "org.jboss.as.web" => undefined,
                "org.jboss.as.webservices" => undefined,
                "org.jboss.as.weld" => undefined
            },
            "interface" => {
                "management" => undefined,
                "public" => undefined,
                "unsecure" => undefined
            },
            "path" => {
                "jboss.server.temp.dir" => undefined,
                "user.home" => undefined,
                "jboss.server.base.dir" => undefined,
                "java.home" => undefined,
                "user.dir" => undefined,
                "jboss.server.data.dir" => undefined,
                "jboss.home.dir" => undefined,
                "jboss.server.log.dir" => undefined,
                "jboss.server.config.dir" => undefined,
                "jboss.controller.temp.dir" => undefined
            },
            "socket-binding-group" => {"standard-sockets" => undefined},
            "subsystem" => {
                "logging" => undefined,
                "configadmin" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "ee" => undefined,
                "ejb3" => undefined,
                "infinispan" => undefined,
                "jaxrs" => undefined,
                "jca" => undefined,
                "jdr" => undefined,
                "jmx" => undefined,
                "jpa" => undefined,
                "mail" => undefined,
                "naming" => undefined,
                "osgi" => undefined,
                "pojo" => undefined,
                "remoting" => undefined,
                "resource-adapters" => undefined,
                "sar" => undefined,
                "security" => undefined,
                "threads" => undefined,
                "transactions" => undefined,
                "web" => undefined,
                "webservices" => undefined,
                "weld" => undefined
            }
        }
    }
    
    
  2. 子ノードに対する read-resource 操作の実行

    read-resource 操作は、ルートから子ノードを問い合わせるために実行できます。操作の構造は最初に公開するノードを定義し、ノードに対して実行する操作を追加します。
    [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource
    以下の例では、特定の Web サブシステムノードに対して read-resource 操作を行うことにより、Web サブシステムコンポーネントに関する固有のリソース情報を公開できます。

    例3.10 ルートノードからの子ノードリソースの公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
    {
        "outcome" => "success",
        "result" => {
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 8433,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    
    同じ結果は、cd コマンドを使用して子ノードに移動し、read-resource 操作を直接実行することにより、得ることができます。

    例3.11 ディレクトリーを変更することにより子ノードリソースを公開

    [standalone@localhost:9999 /] cd subsystem=web
    
    [standalone@localhost:9999 subsystem=web] cd connector=http
    
    [standalone@localhost:9999 connector=http] :read-resource
    {
        "outcome" => "success",
        "result" => {
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 8433,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    
  3. 再帰的なパラメーターを使用して結果にアクティブな値を含める

    再帰的なパラメーターを使用して、永続的でない値、起動時に渡された値、またはランタイムモデルでアクティブな他の属性を含むすべての属性の値を公開できます。
    [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
    以前の例と比較して、include-runtime 要求プロパティーを含めることにより、http コネクターにより送信されたバイトや受信されたバイトなどの追加のアクティブな属性が公開されます。

    例3.12 include-runtime パラメーターを使用して追加でアクティブな値を公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
    {
        "outcome" => "success",
        "result" => {
            "bytesReceived" => "0",
            "bytesSent" => "0",
            "enable-lookups" => false,
            "enabled" => true,
            "errorCount" => "0",
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "maxTime" => "0",
            "name" => "http",
            "processingTime" => "0",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 8433,
            "requestCount" => "0",
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    

3.4.7. 管理 CLI を使用した利用可能なリソース説明の表示

手順3.20 タスク

  1. read-resource-description の実行

    管理 CLI で、read-resource-description 操作を使用して利用可能なリソースを読み取り、表示します。操作要求の詳細については、トピック「管理 CLI での操作とコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-resource-description
  2. オプションパラメーターの使用

    read-resource-description 操作では、追加パラメーターを使用できます。
    1. リソースの操作の説明を含めるには、operations パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(operations=true)
    2. リソースの継承された操作の説明を含める、または除外するには、inherited パラメーターを使用します。デフォルトの状態は true です。
      [standalone@localhost:9999 /]:read-resource-description(inherited=false)
    3. 子リソースの操作の再帰的な説明を含めるには、recursive パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(recursive=true)
    4. リソースの説明を含めるには、locale パラメーターを使用します。null の場合は、デフォルトのロケールが使用されます。
      [standalone@localhost:9999 /]:read-resource-description(locale=true)
結果

利用可能なリソースの説明が表示されます。

3.4.8. 管理 CLI を使用したアプリケーションサーバーのリロード

手順3.21 タスク

  • reload 操作の実行

    管理 CLI で、reload 操作を使用して System.exit(0) システムコールを介してサーバーをシャットダウンします。操作要求の詳細については、トピック「管理 CLI での操作とコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:reload
    {"outcome" => "success"}
    
結果

すべてのサービスをシャットダウンし、ランタイムを再び起動することにより、アプライアンスサーバーがリロードされます。管理 CLI が自動的に再接続されます。

3.4.9. 管理 CLI を使用したアプリケーションサーバーのシャットダウン

手順3.22 タスク

  • shutdown 操作の実行

    管理 CLI で、shutdown 操作を使用し System.exit(0) システムコールを介してサーバーをシャットダウンします。操作要求の詳細については、トピック「管理 CLI での操作とコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:shutdown
結果

アプリケーションサーバーがシャットダウンされます。ランタイムが利用できない場合に、管理 CLI が切断されます。

3.4.10. 管理 CLI での属性の設定

概要

write-attribute 操作は、選択されたリソース属性を記述または変更するために使用するグローバル操作です。この操作を使用して永続的な変更を行い、管理対象サーバーインスタンスの設定を変更できます。要求プロパティーには以下のパラメーターが含まれます。

要求プロパティー

name
選択されたリソース下で値を設定する属性の名前。
value
選択されたリソース下の属性の必要な値。基礎となるモデルが null 値をサポートする場合は、null になることがあります。

手順3.23 タスク

  • write-attribute 操作の実行

    管理 CLI で、write-attribute 操作を使用してリソース属性の値を変更します。操作は、完全リソースパスが指定されたリソースの子ノードまたは管理 CLI のルートノードで実行できます。

例3.13 write-attribute 操作でデプロイメントスキャナーを無効にします。

以下の例では、write-attribute 操作を使用してデプロイメントスキャナーを無効にします。操作は、ルートノードから実行されます (タブ補完を使用して正しいリソースパスを入力します)。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}

操作の結果は、read-attribute 操作を直接使用して確認できます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}

また、結果は、read-resource 操作を使用して、すべてのノードの利用可能なリソース属性をリストすることによっても確認できます。以下の例では、この特別な設定により、scan-enabled 属性が false に設定されていることが示されます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}

結果

リソース属性が更新されます。

3.5. 管理 CLI コマンド履歴

3.5.1. 管理 CLI コマンド履歴の利用

管理 CLI にはコマンドの履歴機能があり、これはアプリケーションサーバーのインストール時にデフォルトで有効になっています。この履歴はアクティブな CLI セッションの揮発性メモリーでレコードとして保持されるか、ユーザーのホームディレクトリーに .jboss-cli-history として自動的に保存されるログファイルに追加されます。この履歴ファイルはデフォルトで、CLI コマンドを最大 500 件記録できるよう設定されます。
history コマンド自体は、現在のセッションの履歴を返しますが、引数を追加すると、セッションメモリーの履歴を無効化、有効化、または消去できます。管理 CLI では、キーボードの矢印キーを使用してコマンドや操作の履歴を前後に移動できます。

3.5.2. 管理 CLI コマンド履歴の表示

手順3.24 タスク

  • history コマンドの実行

    管理 CLI で、history コマンドを入力します。
    [standalone@localhost:9999 /] history
結果

CLI が起動された以降、または履歴削除コマンドが実行された以降にメモリに格納された CLI コマンド履歴が表示されます。

3.5.3. 管理 CLI コマンド履歴の削除

手順3.25 タスク

  • history --clear コマンドの実行

    管理 CLI で、history --clear コマンドを入力します。
    [standalone@localhost:9999 /] history --clear
結果

CLI が起動された以降に記録されたコマンドの履歴がセッションメモリーから削除されます。コマンド履歴は、ユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルにまだあります。

3.5.4. 管理 CLI コマンド履歴の無効化

手順3.26 タスク

  • history --disable コマンドの実行

    管理 CLI で、history --disable コマンドを入力します。
    [standalone@localhost:9999 /] history --disable
結果

CLI で実行されたコマンドは、メモリ内、またはユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されません。

3.5.5. 管理 CLI コマンド履歴の有効化

手順3.27 タスク

  • history --enable コマンドの実行

    管理 CLI で、history --enable コマンドを入力します。
    [standalone@localhost:9999 /] history --enable
結果

CLI で実行されたコマンドは、メモリ内、またはユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されます。

第4章 ユーザー管理

4.1. ユーザー作成

4.1.1. 管理インターフェースの初期ユーザーの追加

概要

JBoss Enterprise Application Platform 6 の管理インターフェースはデフォルトでセキュアになっており、デフォルトのユーザーが存在しません。これは、単純な設定ミスのため、リモートシステムからセキュリティー違反が発生することを防ぐためのセキュリティー予防措置です。ローカルの HTTP 以外のアクセスは、SASL メカニズムによって保護され、ローカルホストからクライアントが初めて接続するたびに、クライアントとサーバー間でネゴシエーションが行われます。

このタスクでは、Web ベースの管理コンソールや管理 CLI のリモートインスタンスを使用してリモートシステムから JBoss Enterprise Application Platform 6 を設定および管理できる初期管理ユーザーを作成する方法について説明します。デフォルトのセキュリティー設定に関する詳細については、「デフォルトのユーザーセキュリティー設定」を参照してください。

注記

JBoss Enterprise Application Platform 6 との HTTP 通信は、トラフィックの送信元がローカルホストであってもリモートアクセスと見なされます。したがって、管理コンソールを使用するには、少なくとも 1 人のユーザーを作成する必要があります。ユーザーを追加する前に管理コンソールにアクセスしようとすると、ユーザーが追加されるまでデプロイされないため、エラーが発生します

手順4.1 タスク

  1. add-user.sh または add-user.bat スクリプトを呼び出します。

    EAP_HOME/bin/ ディレクトリーへ移動します。ご使用のオペレーティングシステムに対応するスクリプトを呼び出します。
    Red Hat Enterprise Linux
    [user@host bin]$ ./add-user.sh
    Microsoft Windows Server
    C:\bin>  add-user.bat
  2. 管理ユーザーの追加を選択します。

    オプション a を選択して管理ユーザーを追加します。このユーザーは ManagementRealm に追加され、Web ベース管理コンソールまたはコマンドラインベース管理 CLI を使用して監理操作を実行することを許可されます。他のオプション b を選択すると、ユーザーが ApplicationRealm に追加され、特定のパーミッションは提供されません。このレルムはアプリケーションで使用するために提供されます。
  3. ユーザーのレルムを選択します。

    次のプロンプトは、ユーザーが追加されるレルムを示します。JBoss Enterprise Application Platform 6 を管理するパーミッションを持つユーザーの場合は、デフォルト値 (ManagementRealm) を選択します。
  4. 希望のユーザー名とパスワードを入力します。

    入力を促されたら、セキュリティーレルム、ユーザー名、パスワードを入力します。ENTER を押すと、管理インターフェースを使用してユーザーが JBoss Enterprise Application Platform 6 を管理できる ManagementRealm のデフォルトレルムが選択されます。このレルムには最低でも 1 人のユーザーを追加する必要があります。情報を確認するよう促されます。内容が適切である場合は yes と入力します。
  5. ユーザーがリモート JBoss Enterprise Application Platform 6 サーバーインスタンスを表すかどうかを選択します。

    管理者以外に、ManagementRealm で JBoss Enterprise Application Platform 6 に追加する必要がある場合がある他の種類のユーザーは、JBoss Enterprise Application Platform 6 の別のインスタンスを表すユーザーであり、メンバーとしてクラスターに参加することを認証できる必要があります。次のプロンプトでは、この目的のために追加されたユーザーを指定できます。yes を選択した場合は、異なる設定ファイルに追加する必要があるユーザーのパスワードを表すハッシュされた secret 値が提供されます。このタスクでは、この質問に対して no と回答してください。
  6. 追加ユーザーを入力します。

    希望する場合はこの手順を繰り返して追加のユーザーを入力することができます。また、稼働中のシステムにいつでもユーザーを追加することが可能です。デフォルトのセキュリティーレルムを選択する代わりに他のレルムにユーザーを追加して、承認を細かく調整することが可能です。
  7. 非対話的にユーザーを作成します。

    コマンドラインで各パラメーターを渡すと非対話的にユーザーを作成することができます。ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。監理レルムを使用した、コマンドの構文は次のとおりです。
    [user@host bin]$ ./add-user.sh usernamepassword
    アプリケーションレルムを使用するには、-a パラメーターを使用します。
    [user@host bin]$ ./add-user.sh -a usernamepassword
結果

追加したすべてのユーザは、指定したセキュリティーレルム内でアクティベートされます。ManagementRealm レルム内でアクティブなユーザーは、リモートシステムから JBoss Enterprise Application Platform 6 を管理できます。

4.1.2. 管理インターフェースにユーザーを追加

第5章 ネットワークおよびポート設定

5.1. インターフェース

5.1.1. インターフェースについて

アプリケーションサーバーは、設定全体で名前付きインターフェース参照を使用します。これにより、使用ごとにインターフェースの完全な詳細を使用するのではなく論理名を使用して個々のインターフェース宣言を参照できるようになります。また、論理名を使用することにより、管理対象ドメインのサーバーインスタンスに、複数のマシンのさまざまなインターフェース詳細が含まれることがある名前付きインターフェースへのグループ参照で整合性を取ることができます。この方法により、各サーバーインスタンスは、インターフェースグループ全体を簡単に管理できる論理名グループに対応できます。
ネットワークインターフェースは、物理インターフェースの論理名と選択基準を指定して宣言されます。アプリケーションサーバーは、管理およびパブリックインターフェース名のデフォルト設定で出荷されます。この設定では、パブリックインターフェースグループは、Web やメッセージングなどのアプリケーション関連ネットワーク通信で使用することを目的としています。管理インターフェースグループは、HTTP 管理エンドポイントを含む管理レイヤーで必要なすべてのコンポーネントとサービスに使用することを目的としています。インターフェース名自体は、推奨例としてのみ提供され、どのグループのどの名前でも必要に応じて置換または作成できます。
domain.xmlhost.xml、および standalone.xml 設定ファイルには、インターフェース宣言が含まれます。宣言基準はワイルドカードアドレスを参照したり、有効な一致候補にするためにインターフェースまたはアドレスで必要となる 1 つまたは複数の特徴を指定したりできます。次の例は、通常は standalone.xml 設定ファイルまたは host.xml 設定ファイルで定義される、インターフェース宣言の複数の設定を示しています。これにより、リモートホストグループが独自の固有インターフェース属性を維持できるようになる一方で、ドメインコントローラーの domain.xml 設定ファイルのインターフェースグループを引き続き参照できます。
最初の例は、management 相対名グループと public 相対名グループに対して指定された固有の inet-address 値を示します。

例5.1 inet-address 値で作成されたインターフェースグループ

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>


次の例では、グローバルインターフェースグループが any-address 要素を使用してワイルドカードアドレスを宣言します。

例5.2 ワイルドカード宣言で作成されたグローバルグループ

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>


次の例では、相対グループ下のネットワークインターフェースカードを名前 external で宣言します。

例5.3 NIC 値で作成された外部グループ

        
<interface name="external">
   <nic name="eth0"/>
</interface>


次の例では、特定の要件に対して宣言がデフォルトグループとして作成されます。このインスタンスでは、追加要素の特徴により、インターフェースの状況が有効な一致候補に設定されます。これにより、固有のインターフェース宣言グループを作成し、事前に設定された方法でこれらを参照して、複数のサーバーインスタンスでの設定時間と管理時間を短縮できます。

例5.4 特定の状況の値で作成されたデフォルトグループ

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>


インターフェース宣言はソース設定ファイルで記述および編集できますが、管理 CLI と管理コンソールは設定変更のために安全で制御された永続的な環境を提供します。

5.1.2. インターフェースの設定

standalone.xml 設定ファイルと host.xml 設定ファイルのデフォルトインターフェース設定は、それぞれの相対インターフェーストークンを持つ 3 つの名前付きインターフェースを提供します。管理コンソールまたは管理 CLI を使用して、以下の表で示されたような追加の属性と値を設定できます。また、必要に応じて、相対インターフェースバインディングを特定の値に置き換えることもできます。置き換える場合、-b スイッチは相対値のみを上書きできるため、サーバーの実行時にインターフェース値を渡すことはできません。

例5.5 デフォルトインターフェース設定

        <interfaces>
            <interface name="management">
                <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
            </interface>
            <interface name="public">
                <inet-address value="${jboss.bind.address:127.0.0.1}"/>
            </interface>
            <interface name="unsecure">
                <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
            </interface>
        </interfaces>

表5.1 インターフェース属性と値

インターフェース要素 説明
any 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
any-address このインターフェースを使用するソケットをワイルドカードアドレスにバインドする必要があることを示す空の要素。java.net.preferIpV4Stack システムプロパティーが true に設定されていない限り、IPv6 ワイルドカードアドレス (::) が使用されます。true に設定された場合は、IPv4 ワイルドカードアドレス (0.0.0.0) が使用されます。ソケットがデュアルスタックマシンの IPv6 anylocal アドレスにバインドされた場合は、IPv6 および IPv4 トラフィックを受け取ることができます。IPv4 (IPv4 マッピング) anylocal アドレスにバインドされた場合は、IPv4 トラフィックのみを受け取ることができます。
any-ipv4-address このインターフェースを使用するソケットを IPv4 ワイルドカードアドレス (0.0.0.0) にバインドする必要があることを示す空の要素。
any-ipv6-address このインターフェースを使用するソケットを IPv6 ワイルドカードアドレス (::) にバインドする必要があることを示す空の要素。
inet-address IPv6 または IPv4 のドット区切り表記の IP アドレス、または IP アドレスに解決できるホスト名。
link-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがリンクローカルであるかどうかを示す空の要素。
loopback インターフェースの選択基準の一部として、ループバックインターフェースであるかどうかを示す空の要素。
loopback-address マシンのループバックインターフェースで実際には設定できないループバックアドレス。IP アドレスが関連付けられた NIC が見つからない場合であっても該当する値が使用されるため、inet-addressType とは異なります。
multicast インターフェースの選択基準の一部として、マルチキャストをサポートするかどうかを示す空の要素。
nic ネットワークインターフェースの名前 (eth0、eth1、lo など)。
nic-match 使用できるインターフェースを見つけるために、マシンで利用可能なネットワークインターフェースの名前を検索する正規表現。
not 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
point-to-point インターフェースの選択基準の一部として、ポイントツーポイントインターフェースであるかどうかを示す空の要素。
public-address インターフェースの選択基準の一部として、公開されたルーティング可能なアドレスを持つかどうかを示す空の要素。
site-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがサイトローカルであるかどうかを示す空の要素。
subnet-match 「スラッシュ表記法」で記述されたネットワーク IP アドレスとアドレスのネットワーク接頭辞のビット数 (たとえば、192.168.0.0/16)。
up インターフェースの選択基準の一部として、現在稼動しているかどうかを示す空の要素。
virtual インターフェースの選択基準の一部として、仮想インターフェースであるかどうかを示す空の要素。
  • インターフェース属性の設定

    必要に応じて、インターフェース属性を設定するために、管理 CLI または管理コンソールを選択します。
    • 管理 CLI でのインターフェース属性の設定

      管理 CLI を使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 新しいインターフェースの追加

        必要な場合は、add 操作を使用して新しいインターフェースを作成します。このコマンドは、管理 CLI セッションのルートから実行できます。次の例では、新しいインターフェースの名前タイトル interfacename12.0.0.2 と宣言された inet-address とともに作成されます。
        /interface=interfacename/:add(inet-address=12.0.0.2)
      2. インターフェース属性の編集

        write 操作を使用して新しい値を属性に書き込みます。タブ補完を使用して、入力するコマンド文字列を補完したり、利用可能な属性を公開したりできます。以下の例では、inet-address 値を 12.0.0.8 に更新します。
        /interface=interfacename/:write(inet-address=12.0.0.8)
      3. インターフェース属性の編集

        read-resource 操作を include-runtime=true パラメーターで実行して値を変更し、サーバーモデルでアクティブな現在のすべての値を公開することを確認します。
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
    • 管理コンソールでのインターフェース属性の設定

      管理コンソールを使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 管理コンソールにログインします。

        管理対象ドメインまたはスタンドアロンサーバーインスタンスの管理コンソールにログインします。
      2. 監理対象ドメインを使用する場合は、適切なプロファイルを選択します。

        右上にある Profiles タブを選択し、次の画面の左上にある Profile メニューから適切なプロファイルを選択します。
      3. ナビゲーションメニューから [Interfaces] 項目を選択します。

        ナビゲーションメニューから [Interfaces] 項目を選択します。
      4. 新しいインターフェースの追加

        1. Add ボタンをクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックして終了します。
      5. インターフェース属性の編集

        1. 編集するインターフェースを選択し Edit ボタンをクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックして終了します。

5.2. ソケットバインディンググループ

5.2.1. ソケットバインディンググループについて

ソケットバインディングとソケットバインディンググループを使用することにより、ネットワークポートと、JBoss Enterprise Application Platform 6 設定で必要なネットワーキングインターフェースとの関係を定義できます。
ソケットバインディングは、ソケットの名前付き設定です。これらの名前付き設定の宣言は、domain.xml 設定ファイルと standalone.xml 設定ファイルの両方で見つけることができます。設定の他のセクションは、論理名でこれらのソケットを参照できます。ソケット設定の完全な詳細を含める必要はありません。これにより、さまざまなマシンで異なる可能性がある相対ソケットを参照できます。
ソケットバインディングは、ソケットバインディンググループ下に収集されます。ソケットバインディンググループは、論理名でグループ化されたソケットバインディング宣言のコレクションです。名前付きグループは、設定全体で参照できます。スタンドアロンサーバーにはこのようなグループが 1 つだけ含まれ、管理対象ドメインインスタンスには複数のグループを含めることができます。管理対象ドメインの各サーバーグループに対してソケットバインディングを作成するか、複数のサーバーグループ間でソケットバインディンググループを共有できます。
名前付きグループを使用すると、管理対象ドメインの場合に、サーバーグループを設定するときにソケットバインディングの特定のグループに、単純化された参照を使用できます。また、一般的に、1 つのシステムでのスタンドアロンサーバーの複数のインスタンスの設定と管理にも使用できます。次の例は、スタンドアロンおよびドメインインスタンスの設定ファイルのデフォルトソケットバインディンググループを示しています。

例5.6 スタンドアロン設定のデフォルトソケットバインディング

standalone.xml 設定ファイルのデフォルトソケットバインディンググループは、standard-sockets 下でグループ化されます。このグループは、同じ論理参照方法を使用して public インターフェースでも参照されます。
   
<socket-binding-group name="standard-sockets" default-interface="public">
    <socket-binding name="http" port="8080"/>
    <socket-binding name="https" port="8443"/>
    <socket-binding name="jacorb" port="3528"/>
    <socket-binding name="jacorb-ssl" port="3529"/>
    <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
    <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
    <socket-binding name="jndi" port="1099"/>
    <socket-binding name="messaging" port="5445"/>
    <socket-binding name="messaging-throughput" port="5455"/>
    <socket-binding name="osgi-http" port="8090" interface="management"/>
    <socket-binding name="remoting" port="4447"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>

例5.7 ドメイン設定のデフォルトソケットバインディング

domain.xml 設定ファイルのデフォルトソケットバインディンググループには standard-socketsha-socketsfull-sockets、および full-ha-sockets の 4 つのグループが含まれます。これらのグループは public と呼ばれるインターフェースでも参照されます。
<socket-binding-groups>
    <socket-binding-group name="standard-sockets" default-interface="public">
        <!-- Needed for server groups using the 'default' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="ha-sockets" default-interface="public">
        <!-- Needed for server groups using the 'ha' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="full-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
    <socket-binding-group name="full-ha-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full-ha' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
    </socket-binding-group>
</socket-binding-groups>

ソケットバインディングインスタンスは、アプリケーションサーバーディレクトリーの standalone.xml ソースファイルと domain.xml ソースファイルで作成および編集できます。バインディングを管理する推奨方法は、管理コンソールまたは管理 CLI を使用することです。管理コンソールを使用する利点には、[General Configuration] セクション下に専用 [Socket Binding Group] 画面があるグラフィカルユーザーインターフェースが含まれます。管理 CLI は、API、バッチ処理とアプリケーションサーバー設定の上位および下位レベルでスクリプトの使用を可能にするコマンドライン方法に基づいたワークフローを提供します。両方のインターフェースにより、変更を永続化したり、サーバー設定に保存したりできます。

5.2.2. ソケットバインディングの設定

ソケットバインディングは固有のソケットバインディンググループに定義できます。スタンドアロンサーバーにはこのようなグループの 1 つである standard-sockets が含まれ、この他のグループを作成することはできません。この他のグループを作成するには、別のスタンドアロンサーバー設定ファイルを作成します。管理対象ドメインでは複数のソケットバインディンググループを作成することが可能で、必要に応じて含まれるソケットバインディングを設定できます。下表は各ソケットバインディングに使用できる属性を表しています。

表5.2 ソケットバインディングの属性

コンポーネント 説明 ロール
名前 設定の他の場所で使用する必要があるソケット設定の論理名。 必須
ポート この設定に基づいたソケットをバインドする必要がある基本ポート。すべてのポートの値をインクリメントまたはデクリメントすることにより、サーバーがこの基本値を上書きするよう設定できることに注意してください。 必須
インターフェース この設定に基づいたソケットをバインドする必要があるインターフェースの論理名。定義されない場合は、囲んでいるソケットバインディンググループから「default-interface」属性の値が使用されます。 任意
複数のアドレス マルチキャストにソケットが使用される場合は、使用するマルチキャストアドレス。 任意
マルチキャストポート 会話のライフサイクルにバインドされます。会話スコープは、要求の長さとセッション長さの間にあり、アプリケーションによって制御されます。 任意
固定ポート 上記のコンテキストでニーズが満たされない場合は、カスタムスコープを定義できます。 任意
  • ソケットバインディンググループのソケットバインディングの設定

    管理 CLI または管理コンソールを選択して、必要に応じてソケットバインディングを設定します。
    • 管理 CLI を使用したソケットバインディングの設定

      管理 CLI を使用してソケットバインディングを設定します。
      1. 新しいソケットバインディングの追加

        add 操作を使用して、必要な場合に新しいアドレス設定を作成します。このコマンドは、管理 CLI セッションのルートから実行できます。この場合、以下の例では、newsocket という新しいソケットバインディングが作成され、port 属性が 1234 として宣言されます。以下の例は、standard-sockets ソケットバインディンググループ上で編集を行うスタンドアロンサーバーおよび管理対象ドメインの両方に適用されます。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
      2. パターン属性の編集

        write 操作を使用して新しい値を属性に書き込みます。タブ補完を使用して、入力するコマンド文字列を補完したり、利用可能な属性を公開したりできます。以下の例では、port 値を 2020 に更新します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
      3. パターン属性の確認

        read-resource 操作で include-runtime=true パラメーターを実行して値を変更し、サーバーモデルでアクティブな現在のすべての値を公開します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
    • 管理コンソールを使用したソケットバインディングの設定

      管理コンソールを使用してソケットバインディングを設定します。
      1. 管理コンソールへのログイン

        管理対象ドメインまたはスタンドアロンサーバーの管理コンソールにログインします。
      2. Profile tab の選択

        右上の Profiles タブを選択します。
      3. ナビゲーションメニューより Socket Binding を選択

        ナビゲーションメニューから Socket Binding メニュー項目を選択します。管理対象ドメインを使用している場合は Socket Binding Groups メニューから希望のグループを選択します。
      4. 新しいソケットバインディングの追加

        1. Add ボタンをクリックします。
        2. NamePort、および Binding Group に必要な値を入力します。
        3. Save をクリックして終了します。
      5. インターフェース属性の編集

        1. 編集するソケットバインディングを選択し、Edit ボタンをクリックします。
        2. NameInterface、または Port など、必要な値を入力します。
        3. Save をクリックして終了します。

5.2.3. JBoss Enterprise Application Platform 6 により使用されるネットワークポート

JBoss Enterprise Application Platform 6 のデフォルト設定で使用されるポートは複数の要因に依存します。
  • 管理対象ドメインまたはスタンドアロンサーバー設定のいずれを使用するか。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。

注記

数値ポートオフセットは、同じ物理サーバーで複数のサーバーを実行する場合にポートの競合を緩和するために設定できます。サーバーが数値ポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループに対するオフセットをデフォルトのポート番号に追加します。たとえば、ソケットバインディンググループの HTTP ポートは 8080 であり、サーバーは 100 のポートオフセットを使用し、その HTTP ポートは 8180 です。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

表5.3 デフォルトのソケットバインディングの参照

名前 ポート マルチキャストポート 詳細 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。 はい はい はい はい
http 8080 デプロイされた Web アプリケーションのデフォルトポート。 はい はい はい はい
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。 はい はい はい はい
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 はい はい いいえ いいえ
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。 はい はい いいえ いいえ
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでピア検出に使用されます。 はい いいえ はい いいえ
jgroups-mping 45700 マルチキャスト。HA クラスタでの初期メンバーシップを検出するために使用されます。 はい いいえ はい いいえ
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。 はい いいえ はい いいえ
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのユニキャストピア検出。 はい いいえ はい いいえ
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
messaging 5445 JMS サービス。 はい はい いいえ いいえ
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。 はい はい いいえ いいえ
messaging-throughput 5455 JMS Remoting により使用されます。 はい はい いいえ いいえ
mod_cluster 23364 JBoss Enterprise Application Platform と HTTP ロードバランサー間の通信に対するマルチキャストポート。 はい いいえ はい いいえ
osgi-http 8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。 はい はい はい はい
remoting 4447 リモート EJB の呼び出しに使用されます。 はい はい はい はい
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。 はい はい はい はい
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。 はい はい はい はい
管理ポート

ソケットバインディンググループ以外に、各ホストコントローラーは管理用にさらに 2 つのポートを開きます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API により使用されるポート

5.2.4. ソケットバインディンググループのポートオフセットについて

ポートオフセットは、該当するサーバーのソケットバインディンググループにより提供されるポート値に追加される数値オフセットです。これにより、単一のサーバーが属するサーバーグループのソケットバインディングを継承します (グループ内の他のサーバーと競合しないようオフセットを使用)。たとえば、ソケットバインディンググループの HTTP ポートが 8080 であり、サーバが 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 です。

5.2.5. ポートオフセットの設定

  • ポートオフセットの設定

    管理 CLI または管理コンソールを選択してポートオフセットを設定します。
    • 管理 CLI を使用したポートオフセットの設定

      管理 CLI を使用してポートオフセットを設定します。
      1. ポートオフセットの編集

        write 操作を使用して新しい値をポートオフセット属性に書き込みます。次の例は、server-twosocket-binding-port-offset 値を 250 に更新します。このサーバーはデフォルトローカルホストグループのメンバーです。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
      2. ポートオフセット属性の確認

        read-resource 操作で include-runtime=true パラメーターを実行して値を変更し、サーバーモデルでアクティブな現在のすべての値を公開します。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
    • 管理コンソールを使用したポートオフセットの設定

      管理コンソールを使用してポートオフセットを設定します。
      1. 管理コンソールにログインします。

        管理対象ドメインの管理コンソールにログインします。
      2. Server タブを選択します。

        右上の Server タブを選択します。
      3. ポートオフセット属性の編集

        1. Configuration Name セクションでサーバーを選択し、Edit ボタンをクリックします。
        2. Port Offset フィールドで必要な値を入力します。
        3. Save ボタンをクリックして終了します。

5.3. IPv6

5.3.1. IPv6 ネットワーキング向け JVM スタック設定の指定

タスクの概要
このトピックでは、設定ファイルを使用した JBoss Enterprise Application Platform 6 インストールでの IPv6 ネットワーキングの有効化について説明します。

手順5.1 タスク

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. IPv4 Stack Java プロパティーを false に変更します。
    -Djava.net.preferIPv4Stack=false
  3. 以下の Java プロパティーを Java VM オプションに追加します。
    -Djava.net.preferIPv6Addresses=true
    例:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

    注記

    元の設定に戻すには、-Djava.net.preferIPv4Stack true に変更し、-Djava.net.preferIPv6Addresses=true を削除します。
結果
IPv6 アドレスを使用できます。

5.3.2. IPv6 ネットワークに対するインターフェース宣言の設定

タスク概要

次の手順に従って、インターフェース inet アドレスを IPv6 のデフォルトに設定します。

手順5.2 タスク

  1. コンソールの右上にある Profile タブを選択します。
  2. General ConfigurationInterfaces オプションを選択します。
  3. 設定する名前付きネットワークインターフェースを選択します。
  4. Edit ボタンをクリックします。
  5. 下記の inet アドレスを設定します。
    ${jboss.bind.address.management:[::1]}
  6. サーバーを再起動し、変更を実装します。

5.3.3. IPv6 アドレス用 JVM スタック設定の指定

タスクの概要
このトピックでは、JBoss Enterprise Application Platform 6 インストールで IPv6 アドレスを優先するよう設定ファイルで設定する方法について説明します。

手順5.3 タスク

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. 以下の Java プロパティーを Java VM オプションに追加します。
    -Djava.net.preferIPv6Addresses=true
    例:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

第6章 データソース管理

6.1. はじめに

6.1.1. JDBC について

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。JDBC ドライバーを参照するデータソースは、アプリケーションで設定します。次に、アプリケーションコードをドライバーに対して記述すると、ドライバーがそのコードをデータベース言語に変換します。これにより、アプリケーションコードを 1 回記述するだけで、正しい JDBC ドライバーが参照される限りは、どのデータベースとでも使用することができます。
JDBC 4.0 の仕様は、次のサイトで定義されています: http://jcp.org/en/jsr/detail?id=221
JDBC とデータソースの使用を開始するにあたっては、JBoss Enterprise Application Platform 6 の管理設定ガイドの JDBC ドライバーのセクションを参照してください。

6.1.2. JBoss Enterprise Application Platform 6 がサポートするデータベース

JBoss Enterprise Application Platform 6 がサポートする JDBC 準拠のデーターベースの一覧は http://www.redhat.com/resourcelibrary/articles/jboss-enterprise-application-platform-supported-configurations を参照してください。

6.1.3. データソースの型

一般的なリソースタイプには、datasourcesXA datasources の 2 つがあります。
非 XA データソースは、トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソースは、トランザクションが複数のデータベースにわたって分散されるアプリケーションによって使用されます。
管理コンソールあるいは管理 CLI でデータソースを作成するときに、データソースの型を指定します。

6.1.4. データソースの例

JBoss Enterprise Application Platform 6 には H2 データベースが含まれています。これは、軽量な関係データベース管理システムで、開発者によるアプリケーションの迅速な構築を可能にします。これがプラットフォームのデータソース例になります。

警告

本番稼働環境では使用しないでください。これは、アプリケーションをテストおよび構築するために必要なすべての標準をサポートする非常に小さい自己完結型のデータソースであり、本番稼働用として堅牢またはスケーラブルではありません。
サポートおよび認定済みのデータソースの一覧は 「JBoss Enterprise Application Platform 6 がサポートするデータベース」 を参照してください。

6.1.5. -ds.xml ファイルのデプロイメント

JBoss Enterprise Application Platform 6 では、データソースはサーバーサブシステムのリソースとして定義されます。以前のバージョンでは、サーバー設定のデプロイメントディレクトリに *-ds.xml データソース設定ファイルが必要でした。*-ds.xml を JBoss Enterprise Application Platform 6 にデプロイするには、http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd のスキーマに従います。

警告

この機能は開発目的でのみ使用するようにしてください。JBoss の管理ツールではサポートされないため、本番環境での使用は推奨されません。

重要

*-ds.xml ファイルをデプロイする場合、すでにデプロイまたは定義されている <driver> エントリーへの参照を使用しなければなりません。

6.2. JDBC ドライバー

6.2.1. 管理コンソールで JDBC ドライバーをインストール

まとめ

お使いのアプリケーションが JDBC データソースに接続する前に、データソースベンダーの JDBC ドライバーを Enterprise Application Platform が利用できる場所にインストールする必要があります。JBoss Enterprise Application サーバーがあると、他のデプロイメントと同じようにこれらのドライバーをデプロイできます。つまり、管理ドメインを使っている場合、サーバーグループ内の複数のサーバーに対してデプロイ可能です。

前提条件

このタスクを行う前に、以下の要件を満たす必要があります。

  • データベースベンダーから JDBC ドライバーをダウンロードします。
  • アーカイブ (ZIP あるいは TAR ファイル) を展開し、実際のドライバーを含む JARファイルを探します。

手順6.1 タスク

  1. 管理コンソールへのアクセス

  2. JAR ファイルをお使いのサーバーあるいはサーバーグループにデプロイします。

    管理ドメインを使っている場合は、JAR ファイルをサーバーグループにデプロイします。使っていない場合はサーバーにデプロイしてください。「管理コンソールを使いアプリケーションをデプロイ」 を参照してください。
結果:

JDBC ドライバーがデプロイされ、お使いのアプリケーションで利用できるようになります。

6.2.2. コアモジュールとしての JDBC ドライバーのインストール

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

手順6.2 タスク

  1. EAP_HOME/modules/ ディレクトリ下にファイルパス構造を作成します。たとえば、MySQL JDBC ドライバーの場合には、次のようなディレクトリ構造を作成します: EAP_HOME/modules/com/mysql/main/
  2. JDBC ドライバーの JAR を main/ サブディレクトリにコピーします。
  3. main/ サブディレクトリに、以下の例のような module.xml ファイルを作成します。

    例6.1 module.xml ファイルの例

    <?xml version="1.0" encoding="UTF-8"?>
    <module xmlns="urn:jboss:module:1.0" name="com.mysql">
      <resources>
        <resource-root path="mysql-connector-java-5.1.15.jar"/>
      </resources>
      <dependencies>
        <module name="javax.api"/>
      </dependencies>
    </module>
    
    
    モジュール名 com.mysql はそのモジュールのディレクトリ構造と一致する必要があります。
  4. サーバーを起動します。
  5. Management CLI を起動します。
  6. 次の CLI コマンドを実行して、JDBC ドライバーモジュールをドライバーとして追加します。
    /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

    例6.2 CLI コマンドの例

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
結果:

JDBC ドライバーのインストールおよびコアモジュールとしての設定が完了し、アプリケーションのデータソースによる参照が可能な状態となりました。

6.2.3. JDBC ドライバーをダウンロードできる場所

下表は、JBoss Enterprise Application Platform で使用される一般的なデータベースの JDBC ドライバーが標準ダウンロードできる場所を表しています。これらのリンクは、Red Hat が管理および監視していない他社の Web サイトにあります。データベースの最新のドライバーについては、データベースベンダーのドキュメントや Web サイトを確認してください。

6.2.4. ベンダー固有クラスへのアクセス

概要

このトピックでは、JDBC 固有クラスを使用するのに必要な手順について説明します。これは、アプリケーションが JDBC API の一部でないベンダー固有の機能を使用する必要がある場合に必要です。

警告

これは、高度な手順であり、JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。

重要

このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。

重要

接続は IronJacamar コンテナによって制御されるため、ベンダー固有の API ガイドラインに厳密に従ってください。

手順6.3 アプリケーションへの依存関係の追加

    • MANIFEST.MF ファイルの設定

      1. テキストエディターでアプリケーションの META-INF/MANIFEST.MF ファイルを開きます。
      2. JDBC モジュールの依存関係を追加し、ファイルを保存します。
        依存関係: MODULE_NAME

        例6.3 依存関係の例

        依存関係: com.mysql
      1. jboss-deployment-structure.xml ファイルの作成

        アプリケーションの META-INF/ または WEB-INF フォルダーで jboss-deployment-structure.xml という名前のファイルを作成します。

        例6.4 サンプル jboss-deployment-structure.xml ファイル

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>
        
        

例6.5 ベンダー固有 API へのアクセス

以下のサンプルは MySQL API にアクセスします。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

6.3. 非 XA データソース

6.3.1. 管理インターフェースによる非 XA データソースの作成

タスクの概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを作成する手順について取り上げます。

前提条件

  • JBoss Enterprise Application Platform 6 サーバーが稼働している必要があります。

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

手順6.4 タスク

    • 管理 CLI

      1. CLI ツールを起動し、サーバーに接続します。
      2. 以下のコマンドを実行して非 XA データソースを作成し、適切に変数を設定します。
        data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
      3. データソースを有効にします。
        data-source enable --name=DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールへログインします。
      2. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの右上より Profile タブを選択します。
          • ドメインモード

            1. コンソールの右上より Profiles タブを選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
        データソースパネル

        図6.1 データソースパネル

      3. 新しいデータソースの作成

        1. Datasources パネル上部にある Add ボタンを選択します。
        2. Create Datasource ウィザードで新しいデータソースの属性を入力し、Next ボタンを押します。
        3. Create Datasource ウィザードで JDBC ドライバーの詳細を入力し、Next ボタンを押します。
        4. Create Datasource ウィザードで接続設定を入力し、Done ボタンを押します。
結果

非 XA データソースがサーバーに追加されます。standalone.xml または domain.xml ファイル、および管理インターフェースで追加を確認することができます。

6.3.2. 管理 CLI でのデータソースの変更

タスクの概要
このトピックでは、管理コマンドラインインターフェースを使用して既存のデータソースを設定するために必要な手順について説明します。

手順6.5 タスク

  1. サーバーを起動します。
  2. CLI の起動
  3. 設定可能な属性の判断

    次のコマンドを実行し、データソースの設定可能なオプションを判断します。
    /subsystem=datasources/data-source=DATASOURCE_NAME:read-resource
  4. 属性の設定

    write-attribute コマンドを使用してデータソース属性を設定します。
    /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
  5. サーバーの再ロード

    サーバーを再ロードして変更を確認します。
    :reload
結果

データソースが変更されます。 変更は管理コンソールと、standalone.xml または domain.xml ファイルで確認できます。データソースを削除するには、以下のコマンドを実行します。

data-source remove --name=DATASOURCE_NAME

6.3.3. 管理 CLI によるデータソースの削除

タスクの概要
このトピックでは、管理コマンドラインインターフェースを使用して JBoss Enterprise Application Platform 6 からデータソースを削除する手順について説明します。

手順6.6 タスク

  • 次のコマンドを実行してデータソースを削除します。
    data-source remove --jndi-name=JNDI_NAME
結果
データソースがサーバーから削除されます。新しいデータソースを作成するには、「管理インターフェースによる非 XA データソースの作成」 を参照してください。

6.4. XA データソース

6.4.1. 管理 CLI を用いた XA データソースの作成

タスクの概要
管理コマンドラインインターフェースを使用して JBoss Enterprise Application Platform 6 へ新しい XA データソースを追加する手順について説明します。

前提条件

データソースリソースプロパティー

  • XA データソースを追加する時に必要なプロパティーは 4 つあります。
    name
    このコマンドに対する XA データソースインスタンスを識別します。
    jndi-name
    XA データソースの JNDI 名を指定します。 java:/ または java:jboss/ で始まらなければなりません。
    driver-name
    XA データソースが使用すべきである JDBC ドライバーを定義します。ドライバーがデプロイされた方法により異なりますが、.jar ファイルの名前かモジュール名になります。
    xa-datasource-class
    javax.sql.XADataSource 実装の完全修飾名。
  • xa-data-source コマンドに使用できるリソースプロパティーの一覧を表示するには、次の管理 CLI コマンドラインを入力します。
    xa-data-source --help --properties

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。このパラメーターは必要ではなくなりました。

手順6.7 タスク

  1. サーバーを起動します。
  2. 管理 CLI を起動します。
  3. 次のコマンドを実行して XA データソースを作成します。
    xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS

    例6.6 コマンドの例

    data-source add --name=MSSQLDS --jndi-name=java:jboss/MSSQLDS --connection-url=jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MSSQLDB --driver-name=sqljdbc4.jar
  4. XA データソースプロパティーの設定

    1. サーバー名の設定

      次のコマンドを実行し、ホストのサーバー名を設定します。
      /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
    2. データベース名の設定

      次のコマンドを実行し、データベース名を設定します。
      /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
  5. データソースを有効にします。
    xa-data-source enable --name=NAME
結果
XA データソースがサーバーに追加されます。更にデータソースを設定するには、「管理 CLI を用いた XA データソースの変更」 を参照してください。

6.4.2. 管理 CLI を用いた XA データソースの変更

タスクの概要
管理コマンドラインインターフェースを使用して既存の XA データソースを変更するために必要な手順について説明します。

手順6.8 タスク

  1. 設定可能な属性の判断

    次のコマンドを実行し、XA データソースの設定可能なオプションを判断します。
    /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:read-resource
  2. 属性の設定

    write-attribute コマンドを使用して XA データソース属性を設定します。
    /subsystem=datasources/xa-data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
  3. サブリソースの設定

    次のコマンドを実行して XA データソースサブリソースを設定します。
    /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
  4. サーバーの再ロード

    サーバーを再ロードして変更を確認します。
    :reload
結果
XA データソースが変更されます。 変更は管理コンソールと、standalone.xml または domain.xml ファイルで確認できます。

6.4.3. 管理 CLI を用いた XA データソースの削除

タスクの概要
管理コマンドラインインターフェースを使用して JBoss Enterprise Application Platform 6 から XA データソースを削除する手順について説明します。

手順6.9 タスク

  • 次のコマンドを実行して XA データソースを削除します。
    xa-data-source remove --jndi-name=JNDI_NAME
結果
サーバーより XA データソースが削除されます。新しい XA データソースを作成する場合は 「管理 CLI を用いた XA データソースの作成」 を参照してください。

6.4.4. XA 復元

6.4.4.1. XA 復元モジュールについて

各 XA リソースは、設定が関連付けられた復元モジュールを必要とします。復元モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
JBoss Enterprise Application Platform は、JDBC および JMS XA リソース用の復元モジュールを提供します。これらのリソースタイプの場合、復元モジュールは自動的に登録されます。カスタムモジュールを使用する必要がある場合は、それをデータソースで登録できます。

6.4.4.2. XA 復元モジュールの設定

ほとんどの JDBC および JMS リソースでは、復元モジュールがリソースに自動的に関連付けられます。この場合は、復元モジュールがリソースに接続して復元を実行することを許可するオプションのみを設定する必要があります。
JDBC または JMS でないカスタムリソースの場合は、サポートされた設定について Red Hat グローバルサポートサービスにお問い合わせください。
これらの各設定属性は、データソースの作成時または作成後に設定できます。設定属性は、Web ベースの管理コンソールまたはコマンドライン管理 CLI を使用して設定できます。XA データソースの設定の一般情報については、「管理 CLI を用いた XA データソースの作成」「管理 CLI を用いた XA データソースの変更」を参照してください。
一般的なデータソース設定属性と、特定のデータベースベンダーに関連する設定詳細については、以下の表を参照してください。

表6.2 一般的な設定属性

属性 説明  
recovery-username
リソースに接続して復元を行うために復元モジュールが使用する必要があるユーザー名。
 
recovery-password
リソースに接続して復元を行うために復元モジュールが使用する必要があるパスワード。
 
recovery-security-domain
リソースに接続して復元を行うために復元モジュールが使用する必要があるセキュリティードメイン。
 
recovery-plugin-class-name
カスタム復元モジュールを使用する必要がある場合は、この属性をモジュールの完全修飾クラス名に設定します。モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
 
recovery-plugin-properties
プロパティーを設定する必要があるカスタム復元モジュールを使用する場合は、この属性をプロパティーに対するカンマ区切りの key=value ペアのリストに設定します。
 

ベンダー固有の設定情報

Oracle
Oracle データソースが不適切に設定された場合は、ログ出力に次のようなエラーが示されることがあります。
WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
このエラーを解決するには、recovery-username で設定された Oracle ユーザーが復元に必要なテーブルにアクセスできる必要があります。以下の SQL ステートメントは、Oracle バグ 5945463 用のパッチが適用された Oracle 11g または Oracle 10g R2 インスタンスに対する適切なステートメントです。
GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
11g よりも前の Oracle 11 バージョンを使用する場合は、最後の EXECUTE ステートメントを以下のように変更します。
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
PostgreSQL
準備された (つまり、XA) トランザクションを有効にする手順については、PostgreSQL ドキュメンテーションを参照してください。PostgreSQL の JDBC ドライバーのバージョン 8.4-701 では、org.postgresql.xa.PGXAConnection にバグがあり、特定の状況で復元が中断されます。このバグは新しいバージョンで修正されています。
MySQL
http://bugs.mysql.com/bug.php?id=12161 に基づき、XA トランザクション復元は一部の MySQL 5 バージョンでは動作しませんでした。この問題は MySQL 6.1 で修正されました。詳細については、バグの URL または MySQL ドキュメンテーションを参照してください。
IBM DB2
IBM DB2 では、キャッシュ後または障害発生後にアプリケーションサーバーが再起動されたときに実行する指定済み再同期ステージ中にのみメソッド XAResource.recover を呼び出すことが期待されます。これは、DB2 実装での設計に関する決定であり、本書の範囲外です。

6.5. データソースセキュリティー

6.5.1. データソースセキュリティーについて

データソースセキュリティーのソリューションには、セキュリティードメインまたはパスワード vault のいずれかを使用することが推奨されます。以下にそれぞれの例を示します。詳細については、以下のドキュメントを参照してください。

例6.7 セキュリティードメインの例

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

例6.8 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

6.6. データソース設定

6.6.1. データソースのパラメーター

表6.3 非 XA および XA データソースに共通のデータソースパラメーター

パラメーター 説明
jndi-name データソースに対する一意の JNDI 名
pool-name データソースの管理プール名
enabled データソースが有効かどうか
use-java-context
データソースをグローバルの JNDI にバインドするかどうか
spy
JDBC 層で spy 機能を有効にします。これで全 JDBC トラフィックをデータソースにロギングします。logging-category パラメーターは org.jboss.jdbc に設定する必要があります。
use-ccm キャッシュ接続マネージャーを有効化
new-connection-sql 接続プールに接続が追加された場合に実行する SQL ステートメント
transaction-isolation
以下のいずれかになります。
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-delimiter 高可用性 (HA) のクラスターデータベース に関する connection-url にある URL の区切り文字 
url-selector-strategy-class-name org.jboss.jca.adapters.jdbc.URLSelectorStrategy インターフェースを実装するクラス
security
セキュリティー設定である子要素が含まれます。表6.8「セキュリティパラメーター」 を参照してください。
validation
検証設定である子要素が含まれます。表6.9「検証パラメーター」 を参照してください。
timeout
タイムアウト設定である子要素が含まれます。表6.10「タイムアウトパラメーター」 を参照してください。
statement
ステートメント設定である子要素が含まれます。表6.11「ステートメントのパラメーター」 を参照してください。

表6.4 非 XA データソースのパラメーター

パラメーター 説明
jta 非 XA データソースの JTA 統合を有効にします。XA データソースには適用されません。
connection-url JDBC ドライバーの接続 URL
driver-class JDBC ドライバークラスの完全修飾名
connection-property
Driver.connect(url,props) メソッドに渡される任意の接続プロパティー。各 connection-property は、文字列名と値のペアを指定します。プロパティー名は名前、値は要素の内容に基づいています。
pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」 を参照してください。

表6.5 XA データソースのパラメーター

パラメーター 説明
xa-datasource-property
実装クラス XADataSource に割り当てるプロパティー。name=value で指定。 setNameという形式で setter メソッドが存在する場合、プロパティーは setName(value) という形式の setter メソッドを呼び出すことで設定されます。
xa-datasource-class
実装クラス javax.sql.XADataSource の完全修飾名
driver
JDBC ドライバーを含むクラスローダーモジュールへの一意参照。driverName#majorVersion.minorVersion. の形式にのみ対応しています。
xa-pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」 および 表6.7「XA プールパラメーター」 を参照してください。
recovery
リカバリー設定である子要素が含まれます。表6.12「リカバリーパラメーター」 を参照してください。

表6.6 非 XA および XA データソースに共通のプールパラメーター

パラメーター 説明
min-pool-size プールが保持する最小接続数
max-pool-size プールが保持可能な最大接続数
prefill 接続プールのプレフィルを試行するかどうか。要素が空の場合は true を示します。デフォルトは、false です。
use-strict-min pool-size が厳密かどうか。デフォルトは false に設定されています。
flush-strategy
エラーがある場合にプールをフラッシュするかどうか。有効値は次の通りです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルトは FailingConnectionOnly です。
allow-multiple-users 複数のユーザーが getConnection (user, password) メソッドを使いデータソースへアクセスするか、また内部プールタイプがこの動作に対応するかを指定します。

表6.7 XA プールパラメーター

パラメーター 説明
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true あるいは false のどちらを返すか
interleaving XA 接続ファクトリのインターリービングを有効にするかどうか
no-tx-separate-pools コンテキスト毎に sub-pool を作成するかどうか。これには Oracle のデータソースが必要ですが、このデータソースは JTA トランザクションの内部、外部に関わらず、XA 接続の利用ができなくなります。
pad-xid Xid のパディングを行うかどうか
wrap-xa-resource
org.jboss.tm.XAResourceWrapper インスタンスの XAResource をラップするかどうか

表6.8 セキュリティパラメーター

パラメーター 説明
user-name 新規接続の作成に使うユーザー名
password 新規接続の作成に使うパスワード
security-domain 認証処理を行う JAAS security-manager 名が入ります。この名前は、JAAS ログイン設定のapplication-policy/name 属性を相関します。
reauth-plugin 物理接続の再認証に使う再認証プラグインを定義します。

表6.9 検証パラメーター

パラメーター 説明
valid-connection-checker
SQLException.isValidConnection(Connection e) 設定を渡し接続の検証を行う org.jboss.jca.adaptors.jdbc.ValidConnectionChecker インターフェースの実装。接続が破棄されると例外となります。このパラメーターがある場合、check-valid-connection-sql よりもこのパラメーターが優先されます。
check-valid-connection-sql プール接続の妥当性を確認する SQL ステートメント。これは、管理接続をプールから取得し利用する場合に呼び出される場合があります。
validate-on-match
接続ファクトリが、指定セットと管理接続がマッチするか確認しようとした場合に、接続レベルの検証を実行するかを指定します。background validation とは相互排他的です。
background-validation
接続が利用前の認証ではなく、バッググラウンドのスレッドで認証済みであることを指定します。validate-on-match とは相互排他的です。
background-validation-minutes バックグラウンド認証を実行する時間数 (分)。
use-fast-fail
true の場合、接続が無効であれば1回目の試行で接続割り当てを失敗させます。デフォルトは false です。
stale-connection-checker
org.jboss.jca.adapters.jdbc.StaleConnectionChecker のインスタンスで、Boolean isStaleConnection(SQLException e) メソッドを渡します。このメソッドが true を返す場合、例外は、SQLExceptionのサブクラスである、org.jboss.jca.adapters.jdbc.StaleConnectionException でラップされます。
exception-sorter
org.jboss.jca.adapters.jdbc.ExceptionSorter のインスタンスで、ブール変数 isExceptionFatal(SQLException e) メソッドを渡します。このメソッドは、例外が connectionErrorOccurred メッセージとして、javax.resource.spi.ConnectionEventListener のインスタンスすべてにブロードキャストされるべきかを検証します。

表6.10 タイムアウトパラメーター

パラメーター 説明
blocking-timeout-millis 接続待機中にブロックする最大時間数 (ミリ秒)。この時間を超過すると、例外が送出されます。これは、接続許可の待機中にブロックするだけで、新規接続の作成に長時間要している場合は例外を送出しません。デフォルトは 30000 (3分) です。
idle-timeout-minutes
アイドル接続が切断されるまでの最大時間 (分)。実際の最大時間は、idleRemover のスキャン時間 (プールの最小 idle-timeout-minutes の半分) に左右されます。
set-tx-query-timeout
トランザクションがタイムアウトされるまでの残存時間数をもとにクエリのタイムアウトを設定するかどうか。トランザクションが存在しない場合は設定済みのクエリタイムアウトのいずれかを利用します。デフォルトは false です。
query-timeout クエリのタイムアウト (秒)。デフォルトはタイムアウトなしです。
allocation-retry 例外を送出する前に接続割り当ての再試行をする回数。デフォルトは 0 で、初回の失敗後に例外が送出されます。
allocation-retry-wait-millis
接続割り当てまで待機する時間数 (ミリ秒)。デフォルトは 5000 で、5秒です。
xa-resource-timeout
ゼロ以外の場合、この値は XAResource.setTransactionTimeout メソッドに渡されます。

表6.11 ステートメントのパラメーター

パラメーター 説明
track-statements
接続がプールに返され、ステートメントが準備済みステートメントのキャッシュに返された時点で、ステートメントが閉じられていることを確認するかどうか。false の場合、ステートメントはトラッキングされません。

有効な値

  • true: ステートメントと結果セットがトラックされ、ステートメントが閉じられていない場合は警告が出されます。
  • false: ステートメントも結果セットもトラッキングされません。
  • nowarn: ステートメントはトラッキングされますが、警告は出されません。これがデフォルト設定となっています。
prepared-statement-cache-size Least Recently User (LRU) キャッシュ内の接続毎の準備済みステートメント数。
share-prepared-statements
ステートメントを閉じずに同じステートメントを2回リクエストする場合に、基盤となる準備済みステートメントは同じものを使うのかどうか。デフォルトは false です。

表6.12 リカバリーパラメーター

パラメーター 説明
recover-credential リカバリーに利用するユーザー名とパスワードのペアあるいは、セキュリティドメイン。
recover-plugin
リカバリーに利用するorg.jboss.jca.core.spi.recoveryRecoveryPlugin の実装クラス。

6.6.2. データソース接続 URL

表6.13

データソース 接続 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

6.6.3. データソースの拡張

データソースのデプロイメントは、JDBC リソースアダプターにある複数の拡張を使うことで、接続の検証を改善し、例外によって接続の再確立を行うべきか確認することができます。これらの拡張とは以下のとおりです。

表6.14 データソースの拡張

データソースの拡張 設定パラメーター 詳細
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> SQLException が発生した接続にとってこの例外は致命的かどうかを確認します。
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> org.jboss.jca.adapters.jdbc.StaleConnectionException の古くなった SQLException をラップします。
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> 接続がアプリケーション利用にも有効かどうかを確認します。
JBoss Enterprise Application Platform 6 には、複数の対応データベースに対応する拡張の実装も含まれています。

拡張の実装

汎用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.7. データソース例

6.7.1. PostgreSQL のデータソースの例

例6.9

PostgreSQL のデータソースの設定例は以下の通りです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されます。
<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 PostgreSQL データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.2. PostgreSQL XA のデータソースの例

例6.10

PostgreSQL XA のデータソースの設定例は以下の通りです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されます。
<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <xa-datasource-property name="User">admin</xa-datasource-property>
    <xa-datasource-property name="Password">admin</xa-datasource-property>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 PostgreSQL XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.3. MySQL のデータソースの例

例6.11

MySQL のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 MySQL データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.4. MySQL XA のデータソースの例

例6.12

MySQL XA のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <xa-datasource-property name="User">admin</xa-datasource-property>
    <xa-datasource-property name="Password">admin</xa-datasource-property>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 MySQL XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.5. Oracle のデータソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

例6.13

Oracle のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 Oracle データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.6. Oracle XA のデータソースの例

例6.14

Oracle XA のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <xa-datasource-property name="User">admin</xa-datasource-property>
    <xa-datasource-property name="Password">admin</xa-datasource-property>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 Oracle XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.7. Microsoft SQLServer のデータソースの例

例6.15

Microsoft SQLServer のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>

上記 Microsoft SQLServer データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.8. Microsoft SQLServer XA のデータソースの例

例6.16

Microsoft SQLServer XA のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <xa-datasource-property name="User">admin</xa-datasource-property>
    <xa-datasource-property name="Password">admin</xa-datasource-property>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 Microsoft SQLServer XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.9. IBM DB2 のデータソースの例

例6.17

IBM DB2 のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 IBM DB2 データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.10. IBM DB2 XA のデータソースの例

例6.18

IBM DB2 XA のデータソース設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <xa-datasource-property name="User">admin</xa-datasource-property>
    <xa-datasource-property name="Password">admin</xa-datasource-property>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

上記 IBM DB2 XA データソースの module.xml ファイルの例は次の通りです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.11. Sybase データソースの例

例6.19

Sybase データソースの設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.jboss.org/ironjacamar/schema/datasources_1_0.xsd">
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:host.at.some.domain:5000/db_name?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>user</user-name>
      <password>pwd</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

6.7.12. Sybase XA データソースの例

例6.20

Sybase XA データソースの設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.jboss.org/ironjacamar/schema/datasources_1_0.xsd">
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <xa-datasource-property name="User">user</xa-datasource-property>
    <xa-datasource-property name="Password">password</xa-datasource-property>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

第7章 モジュールの設定

7.1. はじめに

7.1.1. モジュール

モジュールは、クラスのロードと依存関係の管理に使用される、クラスの論理的なグループです。JBoss Enterprise Application Platform 6 では、静的モジュールと動的モジュールと呼ばれる 2 種類のモジュールが存在します。ただし、この 2 種類のモジュールの違いは、パッケージ化の方法のみです。すべてのモジュールは同じ機能を提供します。
静的モジュール
静的モジュールは、アプリケーションサーバーの EAP_HOME/modules/ ディレクトリに事前定義されます。各サブディレクトリは 1 つのモジュールを表し、1 つまたは複数の JAR ファイルと設定ファイル (module.xml) が含まれます。モジュールの名前は、module.xml ファイルで定義されます。アプリケーションサーバーで提供されるすべての API (Java EE API や JBoss Logging などの他の API を含む) は、静的モジュールとして提供されます。
カスタム静的モジュールの作成は、同じサードパーティーライブラリを使用する同じサーバー上に多くのアプリケーションがデプロイされる場合に役立ちます。これらのライブラリを各アプリケーションとバンドルする代わりに、JBoss 管理者はこれらのライブラリが含まれるモジュールを作成およびインストールできます。アプリケーションは、カスタム静的モジュールで明示的な依存関係を宣言できます。
動的モジュール
動的モジュールは、各 JAR または WAR デプロイメント (または、EAR 内のサブデプロイメント) に対してアプリケーションサーバーによって作成およびロードされます。動的モジュールの名前は、デプロイされたアーカイブの名前から派生されます。デプロイメントはモジュールとしてロードされるため、依存関係を設定でき、他のデプロイメントが依存関係として使用できます。
モジュールは必要なときのみロードされます。通常、明示的または暗黙的な依存関係があるアプリケーションがデプロイされるときのみ、モジュールがロードされます。

7.1.2. グローバルモジュール

グローバルモジュールは JBoss Enterprise Application Platform 6 が各アプリケーションへの依存関係として提供するモジュールです。アプリケーションサーバーのグローバルモジュールリストに追加すれば、どのモジュールもグローバルモジュールとなります。モジュールの変更は必要ありません。

7.1.3. モジュールの依存関係

モジュール依存関係とは、あるモジュールが機能するには別のモジュールのクラスを必要とする宣言のことです。モジュールはいくつでも他のモジュールの依存関係を宣言することができます。アプリケーションサーバーがモジュールをロードする時、モジュールクラスローダーがモジュールの依存関係を解析し、各依存関係のクラスをクラスパスに追加します。指定の依存関係が見つからない場合、モジュールはロードできません。
デプロイされたアプリケーション (JAR および WAR) は動的モジュールとしてロードされ、依存関係を用いて JBoss Enterprise Application Platform 6 によって提供される API へアクセスします。
依存関係には明示的と暗黙的の 2 つのタイプがあります。
明示的な依存関係は開発者によって設定に宣言されます。静的モジュールは依存関係を modules.xml ファイルに宣言することができます。動的モジュールはデプロイメントの MANIFEST.MF または jboss-deployment-structure.xml 記述子に依存関係を宣言することができます。
暗示的な依存関係は任意として指定することができます。任意の依存関係をロードできなくても、モジュールのロードに失敗する原因にはなりません。しかし、依存関係が後で使用できるようになっても、モジュールのクラスパスには追加されません。モジュールがロードされる時に依存関係が使用できなければなりません。
暗黙的な依存関係は、特定の条件やメタデータがデプロイメントで見つかった場合に自動的に追加されます。JBoss Enterprise Application Platform に含まれる Java EE 6 API は、デプロイメントに暗黙的な依存関係が検出された時に追加されるモジュールの例になります。
デプロイメントを設定して特定の暗黙的な依存関係を除外することも可能です。この設定は jboss-deployment-structure.xml デプロイメント記述子ファイルで行います。これは、アプリケーションサーバーが暗黙的な依存関係として追加しようとする特定バージョンのライブラリをアプリケーションがバンドルする場合に一般的に用いられます。
モジュールのクラスパスには独自のクラスとその直接の依存関係のみが含まれます。モジュールは 1 つの依存関係の依存関係クラスにはアクセスできませんが、暗示的な依存関係がエクスポートされたことを指定することができます。エクスポートされた依存関係は、エクスポートするモジュールに依存するモジュールへ提供されます。

例7.1 モジュールの依存関係

モジュール A はモジュール B に依存し、モジュール B はモジュール C に依存します。モジュール A はモジュール B のクラスにアクセスでき、モジュール B はモジュール C のクラスにアクセスできます。以下の場合を除き、モジュール A はモジュール C のクラスにはアクセスできません。
  • モジュール A がモジュール C への明示的な依存関係を宣言する場合。
  • または、モジュール B がモジュール B の依存関係をモジュール C でエクスポートする場合。

7.1.4. サブデプロイメントクラスローダーの分離

エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モジュールで、他のサブデプロイメントのリソースにはアクセスすることはできません。これがサブデプロイメントクラスローダーの分離と呼ばれます。
JBoss Enterprise Application Platform 6 では、厳密なサブデプロイメントクラスローダーの分離がデフォルトで無効になっています。必要な場合は有効にできます。

7.2. すべてのデプロイメントに対してサブデプロイメントモジュール隔離を無効化

このタスクでは、サーバー管理者がアプリケーションサーバーでサブデプロイメントモジュール隔離を無効化する方法について示します。これにより、すべてのデプロイメントが影響を受けます。

警告

このタスクでは、サーバーの XML 設定ファイルを編集する必要があります。この作業を行う前に、サーバーを停止する必要があります。最終リリースの監理ツールではこのタイプの設定がサポートされるため、これは一時的な措置です。
  1. サーバーを停止する

    JBoss Enterprise Application Platform サーバーを停止します。
  2. サーバー設定ファイルを開く

    サーバー設定ファイルをテキストエディターで開きます。
    このファイルは、管理ドメインまたはスタンドアロンサーバーによって異なります。また、デフォルト以外の場所とファイル名が使用されることがあります。デフォルトの設定ファイルは、 domain/configuration/domain.xml (管理ドメインの場合) と standalone/configuration/standalone.xml (スタンドアロンサーバー) です。
  3. EE サブシステム設定を特定する

    設定ファイルの EE サブシステム設定要素を特定します。設定ファイルの <profile> 要素には、複数のサブシステム要素が含まれます。EE サブシステム要素には urn:jboss:domain:ee:1.0 のネームスペースがあります。
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.0" />
    
       ...
    デフォルト設定は単一の自己終了タグを持ちますが、カスタム設定は、以下のような個別の開始タグと終了タグ (タグ間に別の要素が含まれることがあります) を持つことがあります。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  4. 自己終了タグを置き換える (必要な場合)

    EE サブシステム要素が単一の自己終了タグである場合は、以下のように適切な開始タグと終了タグで置き換えます。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  5. ear-subdeployments-isolated 要素を追加する

    以下のように、ear-subdeployments-isolated 要素を EE サブシステム要素の子として追加し、false の内容を追加します。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. サーバーを起動する

    JBoss Enterprise Application Platform サーバーを再起動し、新しい設定で実行します。
結果:

サーバーが、すべてのデプロイメントに対して無効化されたサブデプロイメントモジュール隔離で実行されます。

7.3. すべてのデプロイメントへのモジュールの追加

このタスクは JBoss 管理者によるグローバルモジュールリストの定義方法を実証します。

前提条件

  1. グローバルモジュールとして設定するモジュールの名前を覚えておく必要があります。JBoss Enterprise Application Platform 6 に含まれる静的モジュールのリストは 「含まれるモジュール」 を参照してください。モジュールが他のデプロイメントにある場合は 「動的モジュールの名前付け」 を参照してモジュール名を判断してください。

手順7.1 グローバルモジュールのリストへモジュールを追加する

  1. 管理コンソールへログインします。「管理コンソールへログイン」
  2. EE Subsystem パネルへ移動します。
    EE Subsystem パネル

    図7.1 EE Subsystem パネル

  3. Global Modules にある Add ボタンをクリックすると、Create Module ダイアログが表示されます。
  4. モジュールの名前と任意でモジュールスロットを入力します。
  5. Save ボタンをクリックして新しいグローバルモジュールを追加するか、 Cancel リンクをクリックしてキャンセルします。
    • Save ボタンをクリックすると、ダイアログが閉じられ指定のモジュールがグローバルモジュールのリストに追加されます。
    • Cancel をクリックするとダイアログが閉じられ、何も変更されません。
結果

グローバルモジュールのリストに追加されたモジュールは各デプロイメントへの依存関係に追加されます。

7.4. 参考資料

7.4.1. 含まれるモジュール

  • asm.asm
  • ch.qos.cal10n
  • com.google.guava
  • com.h2database.h2
  • com.sun.jsf-impl
  • com.sun.jsf-impl
  • com.sun.xml.bind
  • com.sun.xml.messaging.saaj
  • gnu.getopt
  • javaee.api
  • javax.activation.api
  • javax.annotation.api
  • javax.api
  • javax.ejb.api
  • javax.el.api
  • javax.enterprise.api
  • javax.enterprise.deploy.api
  • javax.faces.api
  • javax.faces.api
  • javax.inject.api
  • javax.interceptor.api
  • javax.jms.api
  • javax.jws.api
  • javax.mail.api
  • javax.management.j2ee.api
  • javax.persistence.api
  • javax.resource.api
  • javax.rmi.api
  • javax.security.auth.message.api
  • javax.security.jacc.api
  • javax.servlet.api
  • javax.servlet.jsp.api
  • javax.servlet.jstl.api
  • javax.transaction.api
  • javax.validation.api
  • javax.ws.rs.api
  • javax.wsdl4j.api
  • javax.xml.bind.api
  • javax.xml.jaxp-provider
  • javax.xml.registry.api
  • javax.xml.rpc.api
  • javax.xml.soap.api
  • javax.xml.stream.api
  • javax.xml.ws.api
  • jline
  • net.sourceforge.cssparser
  • net.sourceforge.htmlunit
  • net.sourceforge.nekohtml
  • nu.xom
  • org.antlr
  • org.apache.ant
  • org.apache.commons.beanutils
  • org.apache.commons.cli
  • org.apache.commons.codec
  • org.apache.commons.collections
  • org.apache.commons.io
  • org.apache.commons.lang
  • org.apache.commons.logging
  • org.apache.commons.pool
  • org.apache.cxf
  • org.apache.httpcomponents
  • org.apache.james.mime4j
  • org.apache.log4j
  • org.apache.neethi
  • org.apache.santuario.xmlsec
  • org.apache.velocity
  • org.apache.ws.scout
  • org.apache.ws.security
  • org.apache.ws.xmlschema
  • org.apache.xalan
  • org.apache.xerces
  • org.apache.xml-resolver
  • org.codehaus.jackson.jackson-core-asl
  • org.codehaus.jackson.jackson-jaxrs
  • org.codehaus.jackson.jackson-mapper-asl
  • org.codehaus.jackson.jackson-xc
  • org.codehaus.woodstox
  • org.dom4j
  • org.hibernate
  • org.hibernate.envers
  • org.hibernate.infinispan
  • org.hibernate.validator
  • org.hornetq
  • org.hornetq.ra
  • org.infinispan
  • org.infinispan.cachestore.jdbc
  • org.infinispan.cachestore.remote
  • org.infinispan.client.hotrod
  • org.jacorb
  • org.javassist
  • org.jaxen
  • org.jboss.as.aggregate
  • org.jboss.as.appclient
  • org.jboss.as.cli
  • org.jboss.as.clustering.api
  • org.jboss.as.clustering.common
  • org.jboss.as.clustering.ejb3.infinispan
  • org.jboss.as.clustering.impl
  • org.jboss.as.clustering.infinispan
  • org.jboss.as.clustering.jgroups
  • org.jboss.as.clustering.service
  • org.jboss.as.clustering.singleton
  • org.jboss.as.clustering.web.infinispan
  • org.jboss.as.clustering.web.spi
  • org.jboss.as.cmp
  • org.jboss.as.connector
  • org.jboss.as.console
  • org.jboss.as.controller
  • org.jboss.as.controller-client
  • org.jboss.as.deployment-repository
  • org.jboss.as.deployment-scanner
  • org.jboss.as.domain-add-user
  • org.jboss.as.domain-http-error-context
  • org.jboss.as.domain-http-interface
  • org.jboss.as.domain-management
  • org.jboss.as.ee
  • org.jboss.as.ee.deployment
  • org.jboss.as.ejb3
  • org.jboss.as.embedded
  • org.jboss.as.host-controller
  • org.jboss.as.jacorb
  • org.jboss.as.jaxr
  • org.jboss.as.jaxrs
  • org.jboss.as.jdr
  • org.jboss.as.jmx
  • org.jboss.as.jpa
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate.infinispan
  • org.jboss.as.jpa.openjpa
  • org.jboss.as.jpa.spi
  • org.jboss.as.jpa.util
  • org.jboss.as.jsr77
  • org.jboss.as.logging
  • org.jboss.as.mail
  • org.jboss.as.management-client-content
  • org.jboss.as.messaging
  • org.jboss.as.modcluster
  • org.jboss.as.naming
  • org.jboss.as.network
  • org.jboss.as.osgi
  • org.jboss.as.platform-mbean
  • org.jboss.as.pojo
  • org.jboss.as.process-controller
  • org.jboss.as.protocol
  • org.jboss.as.remoting
  • org.jboss.as.sar
  • org.jboss.as.security
  • org.jboss.as.server
  • org.jboss.as.standalone
  • org.jboss.as.threads
  • org.jboss.as.transactions
  • org.jboss.as.web
  • org.jboss.as.webservices
  • org.jboss.as.webservices.server.integration
  • org.jboss.as.webservices.server.jaxrpc-integration
  • org.jboss.as.weld
  • org.jboss.as.xts
  • org.jboss.classfilewriter
  • org.jboss.com.sun.httpserver
  • org.jboss.common-core
  • org.jboss.dmr
  • org.jboss.ejb-client
  • org.jboss.ejb3
  • org.jboss.iiop-client
  • org.jboss.integration.ext-content
  • org.jboss.interceptor
  • org.jboss.interceptor.spi
  • org.jboss.invocation
  • org.jboss.ironjacamar.api
  • org.jboss.ironjacamar.impl
  • org.jboss.ironjacamar.jdbcadapters
  • org.jboss.jandex
  • org.jboss.jaxbintros
  • org.jboss.jboss-transaction-spi
  • org.jboss.jsfunit.core
  • org.jboss.jts
  • org.jboss.jts.integration
  • org.jboss.logging
  • org.jboss.logmanager
  • org.jboss.logmanager.log4j
  • org.jboss.marshalling
  • org.jboss.marshalling.river
  • org.jboss.metadata
  • org.jboss.modules
  • org.jboss.msc
  • org.jboss.netty
  • org.jboss.osgi.deployment
  • org.jboss.osgi.framework
  • org.jboss.osgi.resolver
  • org.jboss.osgi.spi
  • org.jboss.osgi.vfs
  • org.jboss.remoting3
  • org.jboss.resteasy.resteasy-atom-provider
  • org.jboss.resteasy.resteasy-cdi
  • org.jboss.resteasy.resteasy-jackson-provider
  • org.jboss.resteasy.resteasy-jaxb-provider
  • org.jboss.resteasy.resteasy-jaxrs
  • org.jboss.resteasy.resteasy-jsapi
  • org.jboss.resteasy.resteasy-multipart-provider
  • org.jboss.sasl
  • org.jboss.security.negotiation
  • org.jboss.security.xacml
  • org.jboss.shrinkwrap.core
  • org.jboss.staxmapper
  • org.jboss.stdio
  • org.jboss.threads
  • org.jboss.vfs
  • org.jboss.weld.api
  • org.jboss.weld.core
  • org.jboss.weld.spi
  • org.jboss.ws.api
  • org.jboss.ws.common
  • org.jboss.ws.cxf.jbossws-cxf-client
  • org.jboss.ws.cxf.jbossws-cxf-factories
  • org.jboss.ws.cxf.jbossws-cxf-server
  • org.jboss.ws.cxf.jbossws-cxf-transports-httpserver
  • org.jboss.ws.jaxws-client
  • org.jboss.ws.jaxws-jboss-httpserver-httpspi
  • org.jboss.ws.native.jbossws-native-core
  • org.jboss.ws.native.jbossws-native-factories
  • org.jboss.ws.native.jbossws-native-services
  • org.jboss.ws.saaj-impl
  • org.jboss.ws.spi
  • org.jboss.ws.tools.common
  • org.jboss.ws.tools.wsconsume
  • org.jboss.ws.tools.wsprovide
  • org.jboss.xb
  • org.jboss.xnio
  • org.jboss.xnio.nio
  • org.jboss.xts
  • org.jdom
  • org.jgroups
  • org.joda.time
  • org.junit
  • org.omg.api
  • org.osgi.core
  • org.picketbox
  • org.picketlink
  • org.python.jython.standalone
  • org.scannotation.scannotation
  • org.slf4j
  • org.slf4j.ext
  • org.slf4j.impl
  • org.slf4j.jcl-over-slf4j
  • org.w3c.css.sac
  • sun.jdk

7.4.2. 動的モジュールの名前付け

すべてのモジュールは JBoss Enterprise Application Platform 6 によってモジュールとしてロードされ、以下の慣例に従って名前が付けられます。
  1. WAR および JAR ファイルのデプロイメントは次の形式で名前が付けられます。
     deployment.DEPLOYMENT_NAME 
    例えば、inventory.war のモジュール名は deployment.inventory.war となり、store.jar のモジュール名は deployment.store.jar となります。
  2. エンタープライズアーカイブ内のサブデプロイメントは次の形式で名前が付けられます。
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    例えば、エンタープライズアーカイブ accounts.ear 内にある reports.war のサブデプロイメントのモジュール名は deployment.accounting.ear.reports.war になります。

第8章 アプリケーションデプロイメント

8.1. アプリケーションデプロイメントについて

JBoss Enterprise Application Platform 6 には、管理および開発環境で使用するさまざまなアプリケーションデプロイメントおよび設定オプションがあります。管理者向けに、管理コンソールと管理 CLI は、本番稼働環境でアプリケーションデプロイメントを管理する理想的なグラフィカルインターフェースおよびコマンドラインインターフェースを提供します。開発者向けに、さまざまなアプリケーションデプロイメントテストオプションには、高度な設定が可能なファイルシステムデプロイメントスキャナー、JBoss Developer Studio などの IDE、Maven を使用したデプロイメントまたはデプロイメント解除が含まれます。

8.2. 管理コンソールでのデプロイ

8.2.1. 管理コンソースでのアプリケーションデプロイメント管理

管理コンソールよりアプリケーションをデプロイすると、使いやすさが利点のグラフィカルインターフェースを使用できます。ご使用のサーバーもしくはサーバーグループにデプロイされているアプリケーションを一目で確認することができる他、必要に応じてアプリケーションを無効にしたり、コンテンツリポジトリから削除することができます。

8.2.2. 管理コンソールを使いアプリケーションをデプロイ

手順8.1 タスク

  1. 管理コンソールの Manage Deployments パネルに移動します。

    1. コンソールの右上から Runtime タブを選択します。
    2. コンソールの左側のメニューから DeploymentsManage Deployments オプションを選択します。
  2. アプリケーションのデプロイ

    デプロイメントの方法は、スタンドアローンサーバーインスタンス、管理ドメインにデプロイするかにより違います。
    • スタンドアローンサーバーインスタンスへデプロイ

      Deployments の表で利用可能なアプリケーションデプロイメントとそのステータスが表示されます。
      利用可能なデプロイメント

      図8.1 利用可能なデプロイメント

      1. スタンドアローンサーバーインスタンスでアプリケーションを有効化

        Deployments の表のEnable ボタンをクリックしアプリケーションデプロイメントを有効にします。
      2. 確定

        confirm ボタンをクリックし、サーバーインスタンスでアプリケーションを有効にすることを確定します。
        スタンドアローンサーバーで利用可能なデプロイメント

        図8.2 スタンドアローンサーバーで利用可能なデプロイメント

    • 管理ドメインへデプロイ

      Deployment Content セクションには、 Content Repository の表が含まれており、利用可能なアプリケーションデプロイメントとそのステータスがすべて表示されます。
      管理ドメインで利用可能なデプロイメント

      図8.3 管理ドメインで利用可能なデプロイメント

      1. 管理ドメインのアプリケーションを有効化

        Content Repository の表から Add to Groups ボタンをクリックします。
      2. サーバーグループの選択

        アプリケーションを追加したいサーバーグループのボックスをそれぞれにチェックマークを付け、Save ボタンをおして継続します。
        アプリケーションデプロイメントでのサーバーグループを選択

        図8.4 アプリケーションデプロイメントでのサーバーグループを選択

      3. 確定

        Server Group Deployments タブをクリックし Server Groups の表を表示します。お使いのアプリケーションはさきほど選択したサーバーグループにデプロイされています。
        サーバーグループにアプリケーションがデプロイされているか確認

        図8.5 サーバーグループにアプリケーションがデプロイされているか確認

結果:

該当のサーバーあるいはサーバーグループにアプリケーションがデプロイされます。

8.2.3. 管理コンソールを使いアプリケーションをアンデプロイ

手順8.2 タスク

  1. 管理コンソールの Manage Deployments パネルに移動します。

    1. コンソールの右上から Runtime タブを選択します。
    2. コンソールの左側のメニューから DeploymentsManage Deployments オプションを選択します。
  2. アプリケーションのアンデプロイ

    アンデプロイメントの方法は、スタンドアローンサーバーインスタンス、管理ドメインにデプロイするかにより違います。
    • スタンドアローンサーバーインスタンスからアンデプロイ

      Deployments の表で利用可能なアプリケーションデプロイメントとそのステータスが表示されます。
      利用可能なデプロイメント

      図8.6 利用可能なデプロイメント

      1. スタンドアローンサーバーインスタンスでアプリケーションを無効化

        Deployments の表の Disable ボタンをクリックしアプリケーションデプロイメントを有効にします。
      2. アプリケーションの無効化を確定

        confirm ボタンをクリックし、サーバーインスタンスでアプリケーションを無効にすることを確定します。
        アプリケーションの無効化を確定

        図8.7 アプリケーションの無効化を確定

    • 管理ドメインからアンデプロイ

      Deployment Content セクションには、 Content Repository の表が含まれており、利用可能なアプリケーションデプロイメントとそのステータスがすべて表示されます。
      管理ドメインで利用可能なデプロイメント

      図8.8 管理ドメインで利用可能なデプロイメント

      1. 管理ドメインのアプリケーションを無効化

        Server Group Deployments をクリックするとサーバーグループとそのグループにデプロイされたアプリケーションのステータスが表示されます。
        サーバーグループのデプロイメント

        図8.9 サーバーグループのデプロイメント

      2. サーバーグループの選択

        Server Group の表からサーバー名をクリックしサーバーグループからアプリケーションをアンデプロイします。
      3. 選択したサーバーからアプリケーションを無効化

        disableボタンをクリックし選択したサーバーのアプリケーションを無効にします。
      4. アプリケーションの無効化を確定

        confirm ボタンをクリックし、サーバーインスタンスでアプリケーションを無効にすることを確定します。
        アプリケーションの無効化を確定

        図8.10 アプリケーションの無効化を確定

      5. 残りのサーバーグループで繰り返しアンデプロイする手順

        他のサーバーグループに対しても随時、繰り返し設定を行います。アプリケーションステータスは Deployments の表でサーバーグループごとに確認されます。
        サーバーグループからアプリケーションがアンデプロイされているか確認

        図8.11 サーバーグループからアプリケーションがアンデプロイされているか確認

結果

該当のサーバーあるいはサーバーグループからアプリケーションがアンデプロイされます。

8.3. 管理 CLI でのデプロイ

8.3.1. 管理 CLI でのアプリケーションデプロイメントの管理

管理 CLI を使用してアプリケーションをデプロイすると、単一のコマンドラインインターフェースでデプロイメントスクリプトを作成および実行できます。このスクリプト機能を使用して、特定のアプリケーションデプロイメントおよび管理シナリオを設定できます。スタンドアロンインスタンスの場合は単一サーバーのデプロイメント状態を管理でき、管理対象ドメインの場合はサーバーのネットワーク全体を管理できます。

8.3.2. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ

手順8.3 タスク

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスとともにdeploy コマンドを入力します。すべてのサーバーグループをデプロイするために --all-server-groups パラメーターを含めます。
    [domain@localhost:9999 /] deploy ~/path/to/test-application.war --all-server-groups
    'test-application.war' deployed successfully.
    • または、--server-groups パラメーターを使用して、デプロイメントに固有なサーバーグループを定義します。
      [domain@localhost:9999 /] deploy ~/path/to/test-application.war --server-groups server_group_1, server_group_2 
      'test-application.war' deployed successfully.
結果

指定されたアプリケーションが、管理対象ドメインのサーバーグループにデプロイされます。

8.3.3. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ解除

手順8.4 タスク

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントのファイル名とともにundeploy コマンドを入力します。--all-relevant-server-groups パラメーターを追加することにより、アプリケーションは最初にデプロイされたサーバーグループからデプロイ解除できます。
    [domain@localhost:9999 /] undeploy test-application.war --all-relevant-server-groups
    Successfully undeployed test-application.war.
結果

指定されたアプリケーションが、デプロイ解除されます。

8.3.4. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのデプロイ

手順8.5 タスク

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスとともに、deploy コマンドを入力します。
    [standalone@localhost:9999 /] deploy ~/path/to/test-application.war 
    'test-application.war' deployed successfully.
結果

指定されたアプリケーションが、スタンドアロンサーバーにデプロイされます。

8.3.5. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのデプロイ解除

手順8.6 タスク

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントのファイル名とともに、undeploy コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war 
    Successfully undeployed test-application.war.
結果

指定されたアプリケーションが、デプロイ解除されます。

8.4. デプロイメントスキャナーでのデプロイ

8.4.1. デプロイメントスキャナーでのアプリケーションデプロイメント管理

デプロイメントスキャナーを用いてスタンドアロンサーバーインスタンスにアプリケーションをデプロイすると、迅速なデプロイメントサイクルに適した方法でアプリケーションの構築とテストを行えます。デプロイメントスキャナーは、デプロイメントの頻度や多様なアプリケーションタイプの挙動などの必要性に合わせて設定できます。

8.4.2. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイ

概要

このタスクは、デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイする方法を示します。「アプリケーションデプロイメントについて」トピックで示されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順8.7 タスク

  1. デプロイメントフォルダーへのコンテンツのコピー

    アプリケーションファイルを、EAP_HOME/standalone/deployments/ にあるデプロイメントフォルダーにコピーします。
  2. デプロイメントスキャンモード

    アプリケーションデプロイメントは、デプロイメントスキャナーモードが自動か、手動かによって異なります。
    • 自動デプロイメント

      デプロイメントスキャナーは、フォルダーのステータスの変更を検出し、「デプロイメントスキャナーマーカーファイルのリファレンス」トピックで定義されたようにマーカーファイルを作成します。
    • 手動デプロイメント

      デプロイメントスキャナーでは、デプロイメントプロセスをトリガーするマーカーファイルが必要です。以下の例では、Unix touch コマンドを使用して新しい .dodeploy ファイルを作成します。

      例8.1 touch コマンドを使用したデプロイ

      [user@host bin]$ touch $EAP_HOME/standalone/deployments/example.war.dodeploy
結果

アプリケーションファイルがアプリケーションサーバーにデプロイされます。マーカーファイルがデプロイメントフォルダーで作成され、デプロイメントの成功を示します。アプリケーションは、管理コンソールで、Enabled と示されます。

例8.2 デプロイメント後のデプロイメントフォルダーコンテンツ

example.war
example.war.deployed

8.4.3. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイ解除

概要

このタスクは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスからアプリケーションをデプロイ解除する方法を示します。「アプリケーションデプロイメントについて」トピックで示されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

注記

デプロイメントスキャナーは、アプリケーション管理の他のデプロイメント方法とともに使用しないでください。管理コンソールによりアプリケーションサーバーから削除されたアプリケーションは、デプロイメントディレクトリーに含まれるマーカーファイルまたはアプリケーションに影響を与えずにランタイムから削除されます。意図しない再デプロイメントや他のエラーの可能性を最小化するには、本番稼働環境で管理に管理 CLI および管理コンソールを使用します。

手順8.8 タスク

  • アプリケーションの再デプロイ

    デプロイメントフォルダーからアプリケーションを削除するか、デプロイメントステータスのみを変更するかに応じて、アプリケーションをデプロイ解除するには 2 つの方法があります。
    • マーカーファイルの削除によるデプロイ解除

      デプロイされたアプリケーションの example.war.deployed マーカーファイルを削除して、ランタイムからのアプリケーションのデプロイ解除を開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをデプロイ解除し、example.war.undeployed マーカーファイルを作成します。アプリケーションは、デプロイメントフォルダーに維持されます。
    • アプリケーションの削除によるデプロイ解除

      デプロイメントディレクトリーからアプリケーションを削除して、ランタイムからのアプリケーションのデプロイ解除を開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをデプロイ解除し、filename.filetype.undeployed マーカーファイルを作成します。アプリケーションは、デプロイメントフォルダーにありません。
結果

アプリケーションファイルは、アプリケーションサーバーからデプロイ解除され、管理コンソールの Deployments 画面に表示されません。

8.4.4. デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションを再デプロイ

概要

このタスクは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスにアプリケーションを再デプロイする方法を示します。「アプリケーションデプロイメントについて」トピックで示されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順8.9 タスク

  • アプリケーションの再デプロイ

    デプロイメントスキャナーでデプロイされたアプリケーションを再デプロイするには、3 つの方法があります。これらの方法はデプロイメントサイクルを開始するためにデプロイメントスキャナーをトリガーし、個々の設定に応じて選択できます。
結果

アプリケーションファイルが再デプロイされます。

8.4.5. デプロイメントスキャナーマーカーファイルのリファレンス

マーカーファイル

マーカーファイルは、デプロイメントスキャナーサブシステムの一部です。これらのファイルは、スタンドアロンサーバーインスタンスのデプロイメントディレクリー内にあるアプリケーションの状態をマークします。マーカーファイルは、アプリケーションと同じ名前を持ち、ファイル接尾辞はアプリケーションのデプロイメントの状態を示します。以下の表に、各マーカーファイルのタイプおよび応答の定義を示します。

例8.4 マーカーファイル例

以下の例は、testapplication.war という名前のアプリケーションの正常にデプロイされたインスタンスのマーカーファイルを示します。
testapplication.war.deployed

表8.1 マーカーファイルタイプ定義

ファイル名接尾辞 生成元 説明
.dodeploy ユーザー生成 コンテンツをランタイムにデプロイまたは再デプロイする必要があることを示します。
.skipdeploy ユーザー生成 アプリケーションの自動デプロイを無効にします。展開されたコンテンツの自動デプロイメントを一時的にブロックする方法として役に立ち、不完全なコンテンツ編集がライブでプッシュされることを防ぎます。スキャナーは zip 形式のコンテンツに対する処理中の変更を検出し、完了するまで待機しますが、zip 形式のコンテンツとともに使用できます。
.isdeploying システム生成 デプロイメントの開始を示します。デプロイメントプロセスが完了すると、マーカーファイルが削除されます。
.deployed システム生成 コンテンツがデプロイされたことを示します。このファイルが削除された場合、コンテンツはアンデプロイされます。
.failed システム生成 デプロイメントの失敗を示します。マーカーファイルには、失敗の原因に関する情報が含まれます。マーカーファイルが削除された場合、コンテンツは自動デプロイメントで再び可視状態になります。
.isundeploying システム生成 .deployed ファイルの削除に対する応答を示します。コンテンツはアンデプロイされ、完了時にマーカーは自動的に削除されます。
.undeployed システム生成 コンテンツがアンデプロイされたことを示します。マーカーファイルを削除しても、コンテンツの再デプロイメントには影響ありません。
.pending システム生成 デプロイメントの指示が、検出された問題の解決を待っているサーバーに送信されます。このマーカーは、グローバルデプロイメントロードブロックとして機能します。この状態が存在する場合、スキャナーは他のコンテンツをデプロイまたはデプロイ解除するようサーバーに指示しません。

8.4.6. デプロイメントスキャナー属性のリファレンス

デプロイメントスキャナーには、管理 CLI に公開された以下の属性が含まれ、これらの属性は write-attribute 操作を使用して設定できます。設定オプションの詳細については、トピック 「管理 CLI でのデプロイメントスキャナーの設定」 を参照してください。

表8.2 デプロイメントスキャナー属性

名前 説明 タイプ デフォルト値
auto-deploy-exploded .dodeploy マーカーファイルなしで、展開されたコンテンツの自動デプロイメントを許可します。基本的な開発シナリオに対してのみ推奨され、開発者またはオペレーティングシステムによる変更中に、展開されたアプリケーションデプロイメントが行われないようにします。 Boolean False
auto-deploy-xml .dodeploy マーカーファイルなしでの XML コンテンツの自動デプロイメントを許可します。 Boolean True
auto-deploy-zipped .dodeploy マーカーファイルなしでの zip 形式のコンテンツの自動デプロイメントを許可します。 Boolean True
deployment-timeout デプロイメントスキャナーでデプロイメントをキャンセルするまでのデプロイメント試行許可時間 (秒単位)。 Long 60
path スキャンする実際のファイルシステムパスを定義します。relative-to 属性が指定された場合は、path 値が、そのディレクトリーまたはパスに対する相対追加分として機能します。 String Deployments
relative-to サーバー設定 XML ファイルの paths セクションで定義されたファイルシステムパスの参照。 String jboss.server.base.dir
scan-enabled scan-interval により起動時にアプリケーションの自動スキャンを許可します。 Boolean True
scan-interval リポジトリーのスキャン間の時間 (ミリ秒単位)。値が 1 未満の場合は、スキャナーが起動時にのみ動作します。 Int 5000

8.4.7. デプロイメントスキャナーの設定

デプロイメントスキャナーは、管理コンソールまたは管理 CLI を使用して設定できます。新しいデプロイメントスキャナーを作成したり、既存のスキャナー属性を管理したりできます。これらには、スキャン間隔、デプロイメントフォルダーの場所、およびデプロイメントをトリガーするアプリケーションファイルタイプが含まれます。

8.4.8. 管理 CLI でのデプロイメントスキャナーの設定

概要

デプロイメントスキャナーを設定するには複数の方法がありますが、管理 CLI を使用すると、バッチスクリプトを使用して、またはリアルタイムで属性を公開および変更できます。read-attribute および write-attribute グローバルコマンドライン操作を使用することにより、デプロイメントスキャナーの動作を変更できます。デプロイメントスキャナー属性に関する詳細は、トピック「デプロイメントスキャナー属性のリファレンス」で定義されています。

デプロイメントスキャナーは、JBoss Enterprise Application Platform 6 のサブシステムであり、standalone.xml で参照できます。
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-enabled="true" scan-interval="5000" auto-deploy-exploded="true"/>
</subsystem>

手順8.10 タスク

  1. 設定するデプロイメントスキャナー属性を決定

    管理 CLI を使用してデプロイメントスキャナーを設定するには、最初に正しい属性名を公開する必要があります。これは、ルートノードで read-resources 操作を使用するか、または cd コマンドを使用してサブシステム子ノードに移動することにより、行えます。また、このレベルで ls コマンドを使用して属性を表示することもできます。
    • read-resource 操作を使用して、デプロイメントスキャナー属性を公開します。

      read-resource 操作を使用して、デフォルトのデプロイメントスキャナーリソースで定義された属性を公開します。
      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => true,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 60,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
      
    • ls コマンドを使用してデプロイメントスキャナー属性を公開

      ls コマンドを -l オプション引数を使用して、サブシステムノード属性、値、およびタイプを含む結果の表を表示します。ls コマンドとその引数の詳細は、ls --help と入力して CLI ヘルプエントリを表示して学習できます。管理 CLI のヘルプメニューの詳細については、トピック「管理 CLI でのヘルプの使用」を参照してください。
      [standalone@localhost:9999 scanner=default] ls -l
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded true                  BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   60                    LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
      
  2. write-attribute 操作を使用してデプロイメントスキャナーを設定

    変更する属性の名前を決定したら、write-attribute を使用して、書き込む属性名と新しい値を指定します。以下のサンプルは、すべて子ノードレベルで実行され、cd コマンドと Tab 補完を使用してデフォルトスキャナーノードに公開および移動できます。
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    
    1. 展開されたコンテンツの自動デプロイメントを有効化

      write-attribute 操作を使用して、展開されたアプリケーションコンテンツの自動デプロイメントを有効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
      
    2. XML コンテンツの自動デプロイメントを無効化

      write-attribute 操作を使用して XML アプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
      
    3. zip 形式のコンテンツの自動デプロイメントを無効化

      write-attribute コマンドを使用して zip 形式のアプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
      
    4. パス属性の設定

      write-attribute 操作を使用して、パス属性を変更し、例の newpathname 値を監視するデプロイメントスキャナーの新しいパス名に置き換えます。変更を反映するにはサーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      
    5. 相対パス属性の設定

      write-attribute 操作を使用して設定 XML ファイルのパスセクションで定義されたファイルシステムパスに対する相対参照を変更します。変更を反映するには、サーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      
    6. デプロイメントスキャナーの無効化

      write-attribute 操作を使用して、scan-enabled 値を false に設定することにより、デプロイメントスキャナーを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
      
    7. スキャン間隔の変更

      write-attribute 操作を使用してスキャン間隔を 5000 ミリ秒から 10000 ミリ秒に変更します。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
      
結果

設定の変更が、デプロイメントスキャナーに保存されます。

8.5. Maven でのデプロイ

8.5.1. Maven によるアプリケーションデプロイメントの管理

Maven を使用してアプリケーションをデプロイすると、デプロイメントのサイクルを既存の開発ワークフローの一部として取り入れることができます。

8.5.2. Maven によるアプリケーションのデプロイ

概要

このタスクは、Maven を使用してアプリケーションをデプロイする方法を示します。示された例では、Jboss Enterprise Application Platform 6 Quick Starts コレクションに含まれる jboss-as-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれます。このプラグインは、アプリケーションサーバーに対してアプリケーションをデプロイおよびデプロイ解除する単純な操作を提供します。

手順8.11 Maven によるアプリケーションのデプロイ

  1. ターミナルセッションで Maven デプロイコマンドを実行

    ターミナルセッションを開き、quickstart サンプルを含むディレクリーに移動します。
  2. Maven デプロイコマンドを実行してアプリケーションをデプロイします。アプリケーションがすでに実行されている場合、アプリケーションはデプロイ解除されます。
    [localhost]$ mvn package jboss-as:deploy
  3. アプリケーションデプロイメントの確認

    • ターミナルウィンドウでの結果の参照

      デプロイメントは、ターミナルウィンドウで操作ログを参照して確認できます。

      例8.5 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 3 seconds
      [INFO] Finished at: Mon Oct 10 17:22:05 EST 2011
      [INFO] Final Memory: 21M/343M
      [INFO] ------------------------------------------------------------------------
      
      
    • サーバーターミナルウィンドウでの結果の参照

      また、デプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例8.6 アプリケーションサーバーでの helloworld アプリケーションの確認

           
      17:22:04,922 INFO  [org.jboss.as.server.deployment] (pool-1-thread-3) Content added at location /home/dryan/EAP_Home/standalone/data/content/2c/39607b0c8dbc6a36585f72866c1bcfc951f3ff/content
      17:22:04,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-as-helloworld.war"
      17:22:04,954 INFO  [org.jboss.weld] (MSC service thread 1-3) Processing CDI deployment: jboss-as-helloworld.war
      17:22:04,973 INFO  [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: jboss-as-helloworld.war
      17:22:04,979 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
      17:22:05,051 INFO  [org.jboss.web] (MSC service thread 1-2) registering web context: /jboss-as-helloworld
      17:22:05,064 INFO  [org.jboss.as.server.controller] (pool-1-thread-3) Deployed "jboss-as-helloworld.war"
      
      
結果

アプリケーションが、アプリケーションサーバーにデプロイされます。

8.5.3. Maven によるアプリケーションのデプロイ解除

概要

このタスクは、Maven を使用してアプリケーションをデプロイする方法を示します。示された例では、Enterprise Application Server Quick Starts コレクションに含まれる jboss-as-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれます。このプラグインは、アプリケーションサーバーに対してアプリケーションをデプロイおよびデプロイ解除する単純な操作を提供します。

手順8.12 Maven によるアプリケーションのデプロイ解除

  1. ターミナルウィンドウで Maven デプロイコマンドを実行

    ターミナルセッションを開き、quickstart サンプルを含むディレクリーに移動します。

    例8.7 helloworld アプリケーションディレクリーに移動します。

    [localhost]$ cd ~/EAP_Quickstarts/helloworld
    
  2. Maven デプロイ解除コマンドを実行してアプリケーションをデプロイ解除します。
    [localhost]$ mvn jboss-as:undeploy
  3. アプリケーションデプロイ解除の確認

    • ターミナルウィンドウでの結果の参照

      デプロイメント解除は、ターミナルウィンドウの操作ログを参照して確認できます。

      例8.8 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] Building JBoss AS Quickstarts: Helloworld
      [INFO]    task-segment: [jboss-as:undeploy]
      [INFO] ------------------------------------------------------------------------
      [INFO] [jboss-as:undeploy {execution: default-cli}]
      [INFO] Executing goal undeploy for /home/dryan/EAP_Quickstarts/helloworld/target/jboss-as-helloworld.war on server localhost (127.0.0.1) port 9999.
      Oct 10, 2011 5:33:02 PM org.jboss.remoting3.EndpointImpl <clinit>
      INFO: JBoss Remoting version 3.2.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.Xnio <clinit>
      INFO: XNIO Version 3.0.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.nio.NioXnio <clinit>
      INFO: XNIO NIO Implementation Version 3.0.0.Beta2
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
      
      
    • サーバーターミナルウィンドウでの結果の参照

      また、デプロイメント解除は、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例8.9 アプリケーションサーバーでの helloworld アプリケーションの確認

           
      17:33:02,334 INFO  [org.jboss.weld] (MSC service thread 1-3) Stopping weld service
      17:33:02,342 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment jboss-as-helloworld.war in 15ms
      17:33:02,352 INFO  [org.jboss.as.server.controller] (pool-1-thread-5) Undeployed "jboss-as-helloworld.war"
      
      
結果

アプリケーションが、アプリケーションサーバーからデプロイ解除されます。

第9章 JBoss Enterprise Application Platform のセキュア化

9.1. セキュリティーサブシステムについて

セキュリティーサブシステムは、Enterprise Application Platform ですべてのセキュリティー機能のインフラストラクチャーを提供します。ほとんどの設定要素は、ほとんど変更する必要がありません。変更する必要がある場合がある唯一の設定要素は、ディープコピーサブジェクトモード を使用するかどうかです。また、システム全体のセキュリティープロパティーを設定できます。ほとんどの設定はセキュリティードメインに関連します。
ディープコピーモード

ディープコピーサブジェクトモードが無効化されている場合 (デフォルト)、セキュリティデータ構造をコピーすると、データ構造全体をコピーするのではなく、オリジナルが参照されます。この動作はより効率的ですが、フラッシュまたはログアウトの操作によって同一の ID の複数のスレッドで件名を消去すると、データ破損が発生する傾向があります。

ディープコピーサブジェクトモードを使用すると、データ構造および作成する全関連データは、クローン可能とマークされていれば完全にコピーされます。このモードは、よりスレッドセーフですが、効率性は低くなります。
システム全体のセキュリティプロパティ

java.security.Security クラスに適用されるシステム全体のセキュリティープロパティーを設定できます。

セキュリティードメインは、1 つまたは複数のアプリケーションが認証、許可、監査、またはマッピングを制御するために使用する Java Authentication and Authorization Service (JAAS) 宣言セキュリティー設定のセットです。デフォルトで、jboss-ejb-policyjboss-web-policy、および other の 3 つのセキュリティードメインが含まれます。管理 API、管理コンソール、および管理 CLI は、other セキュリティードメインを使用します。アプリケーションのニーズに対応するために、セキュリティードメインを必要な数作成できます。

9.2. セキュリティーサブシステムの構造

セキュリティーサブシステムは管理されたドメインまたはスタンドアロン設定ファイルに設定されます。設定要素のほとんどは Web ベースの管理コンソールかコンソールベースの管理 CLI を使用して設定することが可能です。以下はセキュリティーサブシステムの例を表す XML になります。

例9.1 セキュリティーサブシステムの設定例

<subsystem xmlns="urn:jboss:domain:security:1.1">
	<security-management>
		...
	</security-management>
	<subject-factory>
		...
	</subject-factory>
    <security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
	<security-properties>
		...
	</security-properties>
</subsystem>		
		

The <security-management><subject-factory><security-properties> 要素はデフォルト設定で空になっています。
セキュリティーサブシステム内の各トップレベル要素にはセキュリティー設定の異なる側面に関する情報が含まれています。
<security-management>
このセクションはセキュリティーサブシステムのハイレベルの挙動を上書きします。各設定は任意になります。ディープコピーサブジェクトモードを除き、これらの設定を変更することはあまりありません。
オプション 説明
deep-copy-subject-mode
スレッドの安全性を高めるためセキュリティートークンへコピーまたはリンクするかどうかを指定します。
authentication-manager-class-name
使用する代替の AuthenticationManager 実装クラス名を指定します。
default-callback-handler-class-name
ログインモジュール内で使用される CallbackHandler 実装のグローバルクラス名を指定します。
authorization-manager-class-name
使用する代替の AuthorizationManager 実装クラス名を指定します。
audit-manager-class-name
使用する代替の AuditManager 実装クラス名を指定します。
identity-trust-manager-class-name
使用する代替の IdentityTrustManager 実装クラス名を指定します。
mapping-manager-class-name
使用する MappingManager 実装クラス名を指定します。
<subject-factory>
サブジェクトファクトリはサブジェクトインスタンスの作成を制御します。呼び出し側を検証するため認証マネージャーを使用することがあります。サブジェクトを確立するため、サブジェクトファクトリは主に JCA コンポーネントに対して使用されます。サブジェクトファクトリを変更する必要があることはあまりありません。
<security-domains>
複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュールおよび JASPI 認証、JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
<security-properties>
java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。

9.3. セキュリティサブシステムの設定

security サブシステムのトップレベル設定には、単一の属性 deep-copy-subject-mode が含まれます。この属性には、security-domains および security-properties の子要素が含まれます。セキュリティサブシステムをの設定には、管理 CLI または Web ベースの管理コンソールを使用することができます。
ディープコピーモード

ディープコピーサブジェクトモードが無効化されている場合 (デフォルト)、セキュリティデータ構造をコピーすると、全データ構造をコピーするのではなく、オリジナルが参照されます。この振る舞いはより効率的ですが、フラッシュまたはログアウトの操作によって同一の ID が付いた複数のスレッドで件名を消去すると、データ破損が発生する傾向があります。

ディープコピーサブジェクトモードを使用すると、データ構造および作成されるべき全関連データは、クローン可能とマークされていれば完全にコピーされます。このモードは、よりスレッドセーフですが、効率性は低くなります。
システム全体のセキュリティプロパティ

java.security.Security クラスに適用するシステム全体のセキュリティプロパティを設定することが可能です。

セキュリティドメイン

セキュリティドメインとは、認証、承認、セキュリティ監査、セキュリティマッピングを制御するために単一または複数のアプリケーションが使用する、 Java Authentication and Authorization Service (JAAS) 宣言型セキュリティ設定のセットです。デフォルトでは、jboss-ejb-policyjboss-web-policy、および other の 3 つのセキュリティドメインが含まれています。管理 API、管理コンソール、および管理 CLI は、other セキュリティドメインを使用します。セキュリティドメインは必要に応じていくつでも作成して、ご使用のアプリケーションのニーズに対応することができます。

9.4. ディープコピーサブジェクトモードについて

ディープコピーサブジェクトモード が無効であるときに (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに、元のデータ構造への参照が作成されます。この挙動は効率的ですが、同一 ID の複数のスレッドがフラッシュまたはログアウトの操作によってサブジェクトを消去すると、データが破損しやすくなります。
ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
ディープコピーサブジェクトモードは、セキュリティーサブシステムの一部として設定されます。

9.5. ディープコピーサブジェクトモードの有効化

Web ベースの管理コンソールか管理 CLI よりディープコピーセキュリティーモードを有効にすることができます。

手順9.1 管理コンソールからディープコピーセキュリティーモードを有効にする

  1. 管理コンソールへログインします。

    通常、管理コンソールは http://127.0.0.1:9990/ のような URL で使用できます。環境に合わせて適切な URL を使用してください。
  2. 管理ドメイン: 適切なプロファイルを選択します。

    管理ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にすることができます。
    プロファイルを選択するには、コンソール表示の右上にある プロファイル ラベルをクリックし、右上にある プロファイル 選択ボックスより変更したいプロファイルを選択します。
  3. Security Subsystem 設定メニューを開きます。

    管理コンソールの右にある セキュリティー メニュー項目を拡大し、セキュリティーサブシステム リンクをクリックします。
  4. deep-copy-subject-mode の値を変更します。

    編集 ボタンをクリックします。Deep Copy Subjects: の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用してディープコピーサブジェクトモードを有効にする

管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。

例9.2 管理ドメイン

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

例9.3 スタンドアロンサーバー

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

9.6. セキュリティードメイン

9.6.1. セキュリティードメインについて

セキュリティードメインは JBoss Enterprise Application Platform のセキュリティーサブシステムの一部になります。セキュリティー設定はすべて管理ドメインのドメインコントローラーかスタンドアローンサーバーによって集中管理されるようになりました。
セキュリティードメインは認証、承認、セキュリティーマッピング、監査の設定によって構成されます。セキュリティードメインは Java 認証承認サービス (JAAS) の宣言的セキュリティーを実装します。
認証とはユーザーアイデンティティーを検証することを言います。セキュリティー用語では、このユーザーをプリンシプルと呼びます。認証と承認は異なりますが、含まれる認証モジュールの多くは承認の処理も行います。
承認とは、許可または禁止されている動作に関する情報が含まれるセキュリティーポリシーのことです。セキュリティー用語では、ロールと呼ばれます。
セキュリティーマッピングとは、情報をアプリケーションに渡す前にプリンシパルやロール、属性から情報を追加、編集、削除する機能のことです。
監査マネージャーは、プロバイダーモジュールを設定することでセキュリティーイベントが報告される方法をコントロールできるようにします。
セキュリティードメインを使用する場合、アプリケーション自体から特定のセキュリティー設定をすべて削除することが可能です。これにより、一元的にセキュリティーパラメーターを変更できるようにします。このような設定構造が有効な一般的な例には、アプリケーションをテスト環境と実稼動環境間で移動するプロセスがあります。

9.6.2. Picketbox

Picketbox は、認証、許可、監査、およびマッピング機能を、Enterprise Application Platform で実行されている Java アプリケーションに提供する基礎的なセキュリティーフレームワークです。単一の構成の単一のフレームワークで、次の機能を提供します。
Picketbox 設定は eXtensible Access Control Markup Language (XACML) と呼ばれるマークアップ言語を使用します。

9.6.3. 認証について

認証とは、サブジェクトを識別し、身分が本物であるか検証することを言います。最も一般的な認証メカニズムはユーザー名とパスワードの組み合わせです。その他の一般的な認証メカニズムは共有キーやスマートカード、指紋などを使用します。 Java Enterprise Edition の宣言的セキュリティーでは成功した認証の結果のことをプリンシパルと呼びます。
Enterprise Application Platform は認証モジュールのプラグ可能なシステムを使用して、組織で既に使用している認証システムへ柔軟に対応し、統合を実現します。各セキュリティードメインには 1 つ以上の設定された認証モジュールが含まれます。各モジュールには挙動をカスタマイズするための追加の設定パラメーターが含まれています。Web ベースの管理コンソール内に認証サブシステムを設定するのが最も簡単な方法です。
認証と承認が関連している場合も多くありますが、認証と承認は同じではありません。含まれている多くの認証モジュールは承認も処理します。

9.6.4. セキュリティードメインでの認証の設定

セキュリティードメインの認証を設定するには、管理コンソールにログインして以下の手順を実行します。

手順9.2 タスク

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 認証サブシステム設定に移動します。

    ビューの最上部の Authentication ラベルをクリックします (まだ設定されていない場合)。
    設定領域が Login ModulesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. 認証モジュールを追加します。

    Add ボタンをクリックして JAAS 認証モジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA から取得されました。詳細については、そのドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで認証が引き続き続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストで認証が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。
    sufficient
    LoginModule は成功する必要がありません。成功した場合は、制御がアプリケーションにすぐに戻ります (認証は LoginModule リストで続行されません)。失敗すると、認証は LoginModule リストで続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、認証は LoginModule リストで続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、キーをクリックするか、変更します。Remove ボタンを使用してオプションを削除します。
結果

認証モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

9.6.5. 承認について

承認とはアイデンティティーを基にリソースへのアクセスを許可または拒否するメカニズムのことです。プリンシパルに提供できる宣言的セキュリティーロールのセットとして実装されます。
Enterprise Application Platform はモジュラーシステムを使用して承認を設定します。各セキュリティードメインに 1 つ以上の承認ポリシーが含まれるようにすることができます。各ポリシーには動作を定義する基本モジュールがあり、特定のフラグや属性より設定されます。Web ベースの管理コンソールを使用すると承認サブシステムを最も簡単に設定できます。
承認は認証とは異なり、通常は認証後に承認が行われます。認証モジュールの多くは承認も処理します。

9.6.6. セキュリティードメインでの承認の設定

セキュリティードメインの承認を設定するには、管理コンソールにログインして以下の手順を実行します。

手順9.3 タスク

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 承認サブシステム設定に移動します。

    ビューの最上部の Authorization ラベルをクリックします (まだ設定されていない場合)。
    設定領域が PoliciesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. ポリシーを追加します。

    Add ボタンをクリックして JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA から取得されました。詳細については、そのドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストで承認が引き続き続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストで承認が続行されます。失敗すると、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。
    sufficient
    LoginModule は成功する必要がありません。成功した場合は、制御がアプリケーションにすぐに戻ります (承認は LoginModule リストで続行されません)。失敗すると、承認は LoginModule リストで続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗すると、LoginModule リストで承認が引き続き続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、キーをクリックするか、変更します。Remove ボタンを使用してオプションを削除します。
結果

承認ポリシーモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

9.6.7. セキュリティー監査について

セキュリティー監査とは、セキュリティーサブシステム内で発生したイベントに応答するため、ログへの書き込みなどのイベントをトリガーすることです。監査のメカニズムは、認証、承認、およびセキュリティーマッピングの詳細と共に、セキュリティードメインの一部として設定されます。
監査にはプロバイダーモジュールが使用されます。含まれているプロバイダーモジュールを使用するか、独自のモジュールを実装することができます。

9.6.8. セキュリティー監査の設定

セキュリティードメインのセキュリティー監査を設定するには、管理コンソールにログインして以下の手順を実行します。

手順9.4 タスク

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 監査サブシステム設定に移動します。

    ビューの最上部の Audit ラベルをクリックします (まだ設定されていない場合)。
    設定領域が Provider ModulesDetails の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。
  3. プロバイダーモジュールを追加します。

    Add ボタンをクリックしてプロアクティブモジュールを追加します。Code セクションに、プロバイダーモジュールのクラス名を入力します。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルをクリックして削除するか、Add ボタンをクリックして正しいオプションで再び追加します。
結果

セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

9.6.9. セキュリティーマッピングについて

セキュリティーマッピングを使用すると、認証または承認が実行された後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。この例の 1 つが、X509 証明書を認証に使用した後、プリンシパルを証明書からアプリケーションが表示できる論理名へ変換することです。
プリンシパル (認証) やロール (承認)、証明情報 (プリンシパルやロールでない属性) をマッピングすることが可能です。
ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。
プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。
属性マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

9.6.10. セキュリティードメインでのセキュリティーマッピングの設定

セキュリティードメインのセキュリティーマッピングを設定するには、管理コンソールにログインして以下の手順を実行します。

手順9.5 タスク

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. マッピングサブシステム設定に移動します。

    ビューの最上部の Mapping ラベルをクリックします (まだ設定されていない場合)。
    設定領域が ModulesDetails の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. モジュールを追加します。

    Add ボタンをクリックしてセキュリティーマッピングモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は、principal、role、attribute、または credential です。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Type を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルキーをクリックして削除するか、新しい値で再び追加します。Remove ボタンを使用してオプションを削除します。
結果

セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

9.6.11. アプリケーションでのセキュリティードメインの使用

概要

アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかにドメインを設定する必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。

手順9.6 セキュリティードメインを使用するようアプリケーションを設定

  1. セキュリティードメインの定義

    セキュリティードメインは、サーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかに定義できます。
    • サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss Enterprise Application Platform インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      otherjboss-web-policy および jboss-ejb-policy セキュリティードメインはデフォルトとして JBoss Enterprise Application Platform 6 に提供されます。次の XML の例は、サーバーの設定ファイルの security サブシステムよりコピーされました。
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      
      
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定することができます。
    • アプリケーションの記述子ファイルにセキュリティードメインを設定

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>        
              
      
      
      これが WEB-INF/jboss-web.xml 記述子に指定できる多くの設定の 1 つになります。
  2. EJB へ必要なアノテーションを追加

    @SecurityDomain および @RolesAllowed アノテーションを使用してセキュリティーを EJB に設定します。次の EJBコードの例は、guest ロールのユーザーによる other セキュリティードメインへのアクセスを制限します。
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    
    その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss Enterprise Application Platform 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。

9.6.12. JACC (Java Authorization Contract for Containers)

9.6.12.1. JACC (Java Authorization Contract for Containers) について

JACC (Java Authorization Contract for Containers) はコンテナと承認サービスプロバイダー間のインターフェースを定義する規格で、これによりコンテナによって使用されるプロバイダーの実装が可能になります。JACC は JSR-115 に定義されており、http://jcp.org/en/jsr/detail?id=115 の Java Community Process Web サイトで確認できます。Java EE バージョン 1.3 より、コアの Java Enterprise Edition (Java EE) 仕様の一部となっています。
JBoss Enterprise Application Platform は、セキュリティーサブシステムのセキュリティー機能内に JACC のサポートを実装します。

9.6.12.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定

JACC (Java Authorization Contract for Containers) を設定するには、適切なモジュールでセキュリティードメインを設定し、適切なパラメーターが含まれるよう jboss-web.xml を編集する必要があります。
セキュリティードメインへの JACC サポートの追加

セキュリティードメインに JACC サポートを追加するには、required フラグセットで JACC 承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは 直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>

JACC を使用するよう Web アプリケーションを設定

jboss-web.xml は デプロイメントの META-INF/ または WEB-INF/ ディレクトリに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain> 要素が含まれるようにし、 さらに <use-jboss-authorization> 要素を true に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>

JACC を使用するよう EJB アプリケーションを設定

セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml 記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar> 要素内では、すべての子 <method-permission> 要素に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。

例9.4 EJB の JACC メソッドパーミッション例

<ejb-jar>
  <method-permission>
    <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
    <role-name>employee</role-name>
    <role-name>temp-employee</role-name>
    <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
    </method>
  </method-permission>
</ejb-jar>
	      

Web アプリケーションと同様にセキュリティードメインを使用して EJB の認証および承認メカニズムを指定することも可能です。セキュリティードメインは <security> 子要素の jboss-ejb3.xml 記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。

例9.5 EJB におけるセキュリティードメイン宣言の例


<security>
  <ejb-name>*</ejb-name>
  <security-domain>myDomain</s:security-domain>
  <run-as-principal>myPrincipal</s:run-as-principal>
</s:security>


9.6.13. JASPI (Java Authentication SPI for Containers)

9.6.13.1. JASPI (Java Authentication SPI for Containers) のセキュリティーについて

Java Application SPI for Containers (JASPI または JASPIC) は Java アプリケーションのプラグ可能なインターフェースです。Java Community Process の JSR-196 に定義されています。この仕様の詳細は http://www.jcp.org/en/jsr/detail?id=196 を参照してください。

9.6.13.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定

JASPI プロバイダーに対して認証するには、<authentication-jaspi> 要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack> 要素で囲まれています。設定の構成は次のとおりです。

例9.6 authentication-jaspi 要素の構成

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>


ログインモジュール自体は標準的な認証モジュールと全く同じように設定されます。
Web ベースの管理コンソールは JASPI 認証モジュールの設定を公開しないため、JBoss Enterprise Application Platform を完全に停止してから、設定を EAP_HOME/domain/configuration/domain.xml または EAP_HOME/standalone/configuration/standalone.xml へ直接追加する必要があります。

9.7. 管理インターフェースセキュリティー

9.7.1. デフォルトのユーザーセキュリティー設定

はじめに

JBoss Enterprise Application Platform 6 のすべての管理インターフェースはデフォルトで保護されます。このセキュリティーには 2 つの異なる形式があります。

  • ローカルインターフェースは、ローカルクライアントとローカルクライアントが接続するサーバーとの間の SASL コントラクトによって保護されます。このセキュリティーメカニズムは、ローカルファイルシステムにアクセスするクライアントの機能に基づきます。ローカルシステムへアクセスできるとクライアントによるユーザーの追加が可能で、他のセキュリティーメカニズムを無効にするよう設定を変更できるからです。これにより、ファイルシステムへ物理的にアクセスできると、他のセキュリティーメカニズムが不要になるという原則が厳守されます。このメカニズムは 4 つの手順で実現されます。

    注記

    HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。
    1. ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
    2. サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
    3. クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
    4. サーバーはトークンを検証し、ファイルを削除します。
  • ローカル HTTP クライアントを含むリモートクライアントはレルムベースのセキュリティーを使用します。管理インターフェースを使用して JBoss Enterprise Application Platform 6 をリモートで設定するパーミッションを持つデフォルトのレルムは ManagementRealm です。このレルム (またはユーザーが作成したレルム) にユーザーを追加できるスクリプトが提供されます。ユーザーの追加の詳細については、JBoss Enterprise Application Platform 6 のインストールガイドの章「Getting Started」を参照してください。ユーザーごとに、ユーザー名、ハッシュ化されたパスワード、およびレルムがファイルに格納されます。JBoss Enterprise Application Platform 6 が管理対象ドメインまたはスタンドアロンサーバーとして設定されている場合、ファイルは別の場所に存在します。
    管理対象ドメイン
    EAP_HOME/domain/configuration/mgmt-users.properties
    スタンドアロンサーバー
    EAP_HOME/standalone/configuration/mgmt-users.properties
    mgmt-users.properties の内容はマスクされていますが、機密ファイルとして取り扱うようにしてください。ファイルモードを、ファイル所有者による読み書きアクセスのみが許可される 600 に設定することが推奨されます。

9.7.2. 管理インターフェースの詳細設定の概要

EAP_HOME/domain/configuration/host.xml または EAP_HOME/standalone/configuration/standalone.xml の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、各インターフェースでユーザー認証に使用する認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
管理サブシステムは、複数の設定可能な属性が含まれる <management> 要素と、以下の 3 つの設定可能な子要素で構成されます。セキュリティーレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
セキュリティーレルム

セキュリティーレルムは、管理 API、管理 CLI、または Web ベースの管理コンソールを介して JBoss Enterprise Application Platform の管理を許可されているユーザーの認証と認証を行います。

デフォルトのインストールに含まれる 2 つの異なるファイルベースのセキュリティーレルムは ManagementRealmApplicationRealm です。これらのセキュリティレルムはそれぞれ -users.properties ファイルを使用してユーザーおよびハッシュ化されたパスワードを保管し、-roles.properties でユーザーとロール間のマッピングを保管します。サポートは LDAP 対応のセキュリティーレルムにも含まれています

注記

独自のアプリケーションにセキュリティーレルムを使用することも可能です。このトピックで説明するセキュリティーレルムは管理インターフェース固有のものです。
送信接続

一部のセキュリティーレルムは、LDAP サーバーなどの外部インターフェースに接続します。送信接続は、この接続の確立方法を定義します。 事前に定義された接続タイプ ldap-connection は、LDAP サーバーに接続して資格情報を検証するための必須およびオプションの属性をすべて設定します。

管理インターフェース

管理インターフェースには、JBoss Enterprise Application Platform の接続および設定方法に関するプロパティーが含まれています。この情報には、名前付きのネットワークインターフェース、ポート、セキュリティーレルム、およびインターフェースに関するその他の設定可能な情報が含まれます。デフォルトのインストールには 2 つのインターフェースが含まれています。

  • http-interface は Web ベースの管理コンソールの設定です。
  • native-interface はコマンドライン管理 CLI および REST ライクな管理 API の設定です。
ホスト管理サブシステムの 3 つの主要な設定可能要素はそれぞれ相関しています。セキュリティーレルムは送信接続を参照し、管理インターフェースはセキュリティーレルムを参照します。

9.7.3. LDAP について

LDAP (Lightweight Directory Access Protocol) はディレクトリの情報をネットワーク全体で保存し分散するプロトコルです。ディレクトリの情報にはユーザー、ハードウェアデバイス、アクセスロール、制限などの情報が含まれます。
LDAP の一般的な実装には OpenLDAP、Microsoft Active Directory、IBM Tivoli Directory Server、Oracle Internet Directory などがあります。
JBoss Enterprise Application Platform には、Web アプリケーションや EJB アプリケーションの認証承認権限として LDAP サーバーを使用できるようにする複数の認証および承認モジュールがあります。

9.7.4. 管理インターフェースに対する LDAP を使用した認証

管理コンソール、管理 CLI、管理 API の認証ソースとして LDAP ディレクトリサーバーを使用するには、以下の手順を実行する必要があります。
  1. LDAP サーバーへの送信接続を作成します。
  2. LDAP 対応のセキュリティレルムを作成します。
  3. 管理インターフェースの新規セキュリティドメインを参照します。
LDAP サーバーへの送信接続を作成します。

LDAP 送信接続には、以下の属性を使用することができます。

表9.1 LDAP 送信接続の属性

属性 必須 説明
名前 はい
この接続を識別するための名前。この名前はセキュリティレルムの定義に使用されます。
url はい
ディレクトリサーバーの URL アドレス
search-dn はい
検索の実行を許可されているユーザーの完全識別名 (DN)
search-credentials はい
検索の実行を許可されているユーザーのパスワード
initial-context-factory いいえ
接続を確立する際に使用する初期コンテキストファクトリ。デフォルトでは com.sun.jndi.ldap.LdapCtxFactory に設定されています。

例9.7 LDAP 送信接続の追加

この例では、以下のプロパティーセットを使用して送信接続を追加します。
  • Search DN: cn=search,dc=acme,dc=com
  • Search Credential: myPass
  • URL: http://127.0.0.1
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=http://127.0.0.1,search-dn=cn=search,dc=acme,dc=com)

例9.8 LDAP 送信出力を示す XML

<outbound-connections>
   <ldap name="ldap_connection" url="ldap://127.0.0.1" search-dn="cn=search,dc=acme,dc=com" search-credential="myPass />
</outboundconnections>	
	

LDAP 対応セキュリティレルムの作成

管理インターフェースは、デフォルトで設定されているプロパティファイルをベースとするセキュリティレルムの代わりに LDAP サーバーに対して認証を行うことができます。LDAP 認証システムは、最初にリモートのディレクトリサーバーとの接続を確立することによって機能します。次に、ユーザーが認証システムに渡したユーザー名を使用して検索を実行し、LDAP レコードで完全修飾識別名 (DN) を探します。資格情報としてユーザーの DN とユーザーによって提供されたパスワードを使用して、新規接続が確立されます。 LDAP サーバーに対してこの認証が成功すると、DN が有効であることが確認されます。

LDAP のセキュリティレルムが機能を実行するには、以下のような属性とエレメントが必要です。
connection
<outbound-connections> で定義されている接続名。LDAP ディレクトリへの接続に使用します。
base-dn
ユーザー検索を開始するためのコンテキストの識別名
recursive
LDAP ディレクトリツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかの指定。デフォルトでは false に設定されています。
user-dn
識別名を持つするユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは dn に設定されています。
子要素として、username-filter または advanced-filter のいずれか一方。
username-filterattribute と呼ばれる単一の属性を取ります。その値は userNamesambaAccountName などのユーザー名を格納する LDAP の属性名です。
advanced-filterfilter と呼ばれる単一の属性を取ります。この属性には、(&(sAMAccountName={0})(memberOf=cn=admin,cn,useres,dc=acme,dc=com)) のような標準的な LDAP 構文のフィルタークエリが含まれています。

例9.9 LDAP 対応のセキュリティレルムを示す XML

この例には、以下のパラメーターを使用します。
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName"
<security-realm name="TestRealm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter-attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>	
	

例9.10 LDAP セキュリティレルムの追加

以下のコマンドはセキュリティレルムを追加し、その属性を設定します。
/host=master/core-service=management/security-realm=ldap_security_realm/:add
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap/:write-attribute(name=connection,value=ldap_connection)
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap/:write-attribute(name=base-dn,value=cn=users,dc=acme,dc=com)
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap/:write-attribute(name=recursive,value=false)
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap/:write-attribute(name=user-dn,value=dn)
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap/:write-attribute(name=username-attribute,value=sambaAccountName)
管理インターフェースへの新規セキュリティドメイン適用

セキュリティドメインの作成が完了したら、管理インターフェースの設定でそのドメインを参照する必要があります。管理インターフェースは、HTTP ダイジェスト認証用のセキュリティレルムを使用します。

例9.11 HTTP インターフェースへのセキュリティレルム適用

この設定が有効になると、Web ベースの管理コンソールは LDAP を使用してユーザーの認証を行います。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
Restart JBoss Enterprise Application Platform を再起動すると、HTTP インターフェースは認証に LDAP サーバーを使用するようになります。

9.7.5. HTTP 管理インターフェースの無効化

管理対象ドメインでは、ドメインメンバーのサーバーではなく、ドメインコントローラー上の HTTP インターフェースへのアクセスのみが必要です。また、実稼働サーバー上では、Web ベースの管理コンソールを完全に無効化することが可能です。

注記

JBoss Operations Network などの他のクライアントも HTTP インターフェースを使用して稼働します。これらのサービスを使用したり、管理コンソール自体を無効にしたい場合は、インターフェースを完全に無効化する代わりに HTTP インターフェースの console-enabled-attributefalse に設定できます。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
HTTP インターフェースへのアクセスを無効にすると、Web ベースの管理コンソールへのアクセスも無効になるため、HTTP インターフェースを完全に削除して無効化できます。
次の JBoss CLI コマンドを使用すると、再度追加する場合に備えて HTTP インターフェースの現在の内容を読み込むことができます。

例9.12 HTTP インターフェースの設定の読み込み

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
HTTP インターフェースを削除するには、次のコマンドを実行します。

例9.13 HTTP インターフェースの削除

/host=master/core-service=management/management-interface=http-interface/:remove
アクセスを再度有効化するには、以下のコマンドを実行し、デフォルト値を使用して HTTP インターフェースを再作成します。

例9.14 HTTP インターフェースの再作成

/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=true)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=interface,value=management)
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=port,value=${jboss.management.http.port:9990})
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ManagementRealm)

9.7.6. デフォルトセキュリティーレルムからのサイレント認証の削除

概要

JBoss Enterprise Application Platform 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。

便利な、ローカルユーザーのサイレント認証は、さらに強力なセキュリティー制御が必要な場合に無効にできます。これは、設定ファイルの security-realm セクション内で local 要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml と管理対象ドメイン用の host.xml の両方に適用されます。特定のサーバー設定に与える可能性がある影響を考えると、local 要素を削除することをお勧めします。
サイレント認証の推奨される削除方法は、管理 CLI を使用して、次の例に示された local 要素を直接削除することです。

例9.15 security-realmlocal 要素の例

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

手順9.7 タスク

  • 管理 CLI でのサイレント認証の削除

    必要に応じて、管理レルムとアプリケーションレルムから local 要素を削除します。
    1. 管理レルムから local 要素を削除します。
      /core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. アプリケーションレルムから local 要素を削除します。
      /core-service=management/security-realm=ApplicationRealm/authentication=local:remove
結果

サイレント認証モードが、ManagementRealmApplicationRealm から削除されます。

9.7.7. JMX サブシステムへのリモートアクセスの無効化

リモート JMX 接続により JDK およびアプリケーション管理オペレーションのトリガーが可能となります。インストールをセキュリティ保護するには、この機能を無効にしてください。リモート接続の設定を削除するか、JMX サブシステムを完全に削除することによって無効にすることができます。JBoss CLI コマンドは管理対象ドメイン設定内のデフォルトのプロファイルを参照します。異なるプロファイルを修正するには、コマンドの /profile=default の部分を変更します。スタンドアロンサーバーの場合には、この部分を完全に削除してください。

注記

リモート処理コネクターはデフォルトで JMX サブシステムから削除されています。以下のコマンドは、開発中にリモート処理コネクターを追加した場合に備えて、参考のために記載します。

例9.16 JMX サブシステムからのリモートコネクターの削除

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

例9.17 JMX サブシステムの削除

管理対象ドメインを使用している場合には、使用しているプロファイルごとにこのコマンドを実行してください。
/profile=default/subsystem=jmx/:remove

9.7.8. 管理インターフェースのセキュリティレルムの設定

管理インターフェースはセキュリティレルムを使用して JBoss Enterprise Application Platform の認証および設定メカニズムへのアクセスを制御します。 本トピックでは、セキュリティレルムの読み込みと設定について説明します。以下に記載するコマンドには管理 CLI を使用します。
セキュリティレルムの設定の読み込み

以下の例は、ManagementRealm セキュリティレルムのデフォルト設定を示しています。mgmt-users.properties というファイルを使用して設定情報を保管します。

例9.18 デフォルトの ManagementRealm

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
セキュリティレルムの書き込み

以下のコマンドは TestRealm というセキュリティレルムを作成し、関連プロパティファイルの名前とディレクトリを設定します。

例9.19 セキュリティレルムの書き込み

/host=master/core-service=management/security-realm=TestRealm/:add
/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:write-attribute(name=path,value=TestUsers.properties)
/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:write-attribute(name=relative-to,value=jboss.domain.config.dir)
管理インターフェースへのセキュリティレルム適用

セキュリティレルムを追加したら、その名前を管理インターフェースにリファレンスとして提供します。

例9.20 管理インターフェースへのセキュリティレルム追加

host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=TestRealm)
管理インターフェースへの変更は JBoss Enterprise Application Platform の再起動後に有効となります。

9.8. ネットワークセキュリティー

9.8.1. 管理インターフェースのセキュア化

概要

テスト環境で、管理インターフェース (管理コンソール、管理 CLI、および他のすべての API 実装から構成されます) にセキュリティーレイヤーがない状態で Enterprise Application Platform 6 を実行することは一般的です。これにより、開発と設定変更を素早く行えるようになります。

また、デフォルトでは、サイレント認証モードが存在し、ホストマシン上のローカルクライアントがユーザー名またはパスワードなしで管理 CLI に接続できるようになります。この動作は、ローカルユーザーと管理 CLI スクリプトに対して便利ですが、必要な場合は無効にできます。この手順については、トピック を参照してください。
本番稼働に移行するために環境のテストおよび準備を開始する場合は、少なくとも以下の方法で管理インターフェースをセキュアにすることが非常に重要です。

9.8.2. JBoss Enterprise Application Platform が使用するネットワークインターフェースの指定

概要

サービスを必要なクライアントにのみアクセスできるようサービスを隔離すると、ネットワークのセキュリティーが強化されます。JBoss Enterprise Application Platform には、デフォルト設定の 2 つのインターフェースが含まれ、どちらもデフォルトで IP アドレス 127.0.0.1 または localhost にバインドされます。インターフェースの 1 つは management と呼ばれ、管理コンソール、CLI、および API によって使用されます。他のインターフェースは public と呼ばれ、アプリケーションをデプロイするために使用されます。これらのインターフェースは、特別なものではありませんが、作業を始める土台として提供されます。

management インターフェースはデフォルトでポート 9990 と 9999 を使用し、public インターフェースはポート 8080 または 8443 (HTTPS を使用する場合) を使用します。
管理インターフェース、パブリックインターフェース、またはその両方の IP アドレスを変更できます。

警告

リモートホストからアクセス可能な他のネットワークインターフェースに管理インターフェースを公開する場合は、セキュリティーの問題に注意してください。ほとんどの場合、管理インターフェースにリモートアクセスを提供することはお勧めしません。
  1. JBoss Enterprise Application Platform を停止します。

    オペレーティングシステムに適切な方法で割り込みを送信して JBoss Enterprise Application Platform を停止します。JBoss Enterprise Application Platform をフォアグラウンドアプリケーションとして実行している場合、通常は Ctrl+C を押してこれを行います。
  2. バインドアドレスを指定して JBoss Enterprise Application Platform を再起動します。

    -b コマンドラインスイッチを使用して特定のインターフェースで JBoss Enterprise Application Platform を起動します。

    例9.21 パブリックインターフェースを指定します。

    EAP_HOME/bin/domain.sh -b 10.1.1.1

    例9.22 管理インターフェースを指定します。

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

    例9.23 各インターフェースに異なるアドレスを指定します。

    EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

    例9.24 すべてのネットワークインターフェースにパブリックインターフェースをバインドします。

    EAP_HOME/bin/domain.sh -b 0.0.0.0
XML 設定ファイルを直接編集してデフォルトのバインドアドレスを変更できますが、これを行うと -b コマンドラインスイッチを使用してランタイム時に IP アドレスを指定できなくなるため、お勧めしません。この作業を行う場合は、XML ファイルを編集する前に JBoss Enterprise Application Platform を完全に停止する必要があります。

9.8.3. JBoss Enterprise Application Platform 6 で動作するようネットワークファイアウォールを設定

概要

ほとんどの本番稼動環境では、ネットワークセキュリティー全体の方針の一部としてファイアウォールを使用します。複数のインスタンスがお互い通信したり、Web サーバーやデータベースなどの外部サービスと通信したりする必要がある場合は、ファイアウォールでこのことを考慮する必要があります。良く管理されたファイアウォールでは、操作する必要があるポートのみが開かれ、特定の IP アドレス、サブネット、およびネットワークプロトコルに対するポートへのアクセスが制限されます。

本書では、ファイアウォールの完全な説明は範囲外です。

前提条件

  • 開く必要があるポートを決定します。それぞれの環境のポートのリストを決定するには、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照してください。
  • ファイアウォールソフトウェアについて理解する必要があります。この手順では、Red Hat Enterprise Linux 6 の system-config-firewall コマンドを使用します。Microsoft Windows Server には、ファイアウォールが組み込まれ、各プラットフォーム用の複数のサードパーティー製ファイアウォールソリューションが利用可能です。
前提

この手順では、以下の前提で環境のファイアウォールを設定します。

  • オペレーティングシステムが Red Hat Enterprise Linux 6 です。
  • JBoss Enterprise Application Platform 6 がホスト 10.1.1.2 で実行されます。オプションで、サーバーには独自のファイアウォールがあります。
  • ネットワークファイアウォールサーバーは、ホスト 10.1.1.1 のインターフェース eth0 で実行され、外部インターフェース eth1 を持ちます。
  • ポート 5445 (JMS で使用されるポート) のトラフィックを JBoss Enterprise Application Platform 6 に転送します。ネットワークファイアウォールで他のトラフィックは許可されません。

手順9.8 タスク

  1. 管理コンソールにログインします。

    管理コンソールにログインします。デフォルトでは、http://localhost:9990/console/ で実行されます。
  2. 管理対象ドメイン: サーバーグループが使用するソケットバインディンググループを決定します。

    各サーバーグループは、ソケットバインディングの集まりであるソケットバインディンググループを使用します。ソケットバインディングはポート名と番号の名前/値ペアです。
    サーバーがグループ化するソケットバインディンググループを決定するには、画面の右上にある Server Groups ラベルをクリックします。次に、Available server group configurations テーブルでサーバーグループの名前をクリックします。画面下部の Server attributes 領域に、サーバーグループが使用するプロファイルとソケットバインディンググループが入力されます。
  3. ソケットバインディンググループが使用するソケットバインディングを決定します。

    管理コンソールの右上にある Profiles ラベルをクリックします。画面の左側に一連のメニューが表示されます。下部のメニュー見出しは General Configuration です。この見出しの下の Socket Binding Groups 項目をクリックします。Socket Binding Declarations 画面が表示されます。最初に、standard-sockets グループが表示されます。異なるグループは、右側のコンボボックスで選択することにより選択できます。

    注記

    スタンドアロンサーバーを使用する場合は、1 つのソケットバインディンググループのみが存在します。
    ソケット名とポートのリストが表示されます (1 ページあたり 6 つの値)。テーブルの矢印ナビゲーションを使用してページを移動できます。
  4. 開く必要があるポートを決定します。

    お使いの環境の特別なポートの機能とニーズによっては、一部のポートがファイアウォールを介してアクセスできる必要があります。ソケットバインディングの目的がわからない場合は、「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」を参照して、デフォルトのソケットバインディングとその目的のリストを確認してください。
  5. JBoss Enterprise Application Platform 6 にトラフィックを転送するようファイアウォールを設定します。

    以下の手順を実行して、必要なポートでトラフィックを許可するようネットワークファイアウォールを設定します。
    1. root ユーザーとしてファイアウォールマシンにログインし、コマンドプロンプトにアクセスします。
    2. system-config-firewall コマンドを実行してファイアウォール設定ユーティリティーを起動します。ファイアウォールシステムにログインした方法に応じて、GUI またはコマンドラインユーティリティーが起動します。このタスクでは、SSH 経由でコマンドラインインターフェースを使用してログインしていることを前提とします。
    3. キーボードで TAB キーを使用して Customize ボタンに移動し、ENTER キーを押します。Trusted Services 画面が表示されます。
    4. どの値も変更せずに、TAB キーを使用して Forward ボタンに移動し、ENTER を押して次の画面に進みます。Other Ports 画面が表示されます。
    5. TAB キーを使用して <Add> ボタンに移動し、ENTER を押します。Port and Protocol 画面が表示されます。
    6. Port / Port Range フィールドに 5445 と入力し、TAB キーを使用して Protocol フィールドに移動し、tcp と入力します。TAB キーを使用して OK ボタンに移動し、ENTER を押します。
    7. TAB キーを使用して、Forward ボタンに移動し、Port Forwarding 画面にアクセスします。
    8. TAB キーを使用して <Add> ボタンに移動し、ENTER キーを押します。
    9. 以下の値を入力してポート 5445 のポート転送を設定します。
      • 送信元インターフェース: eth1
      • プロトコル: tcp
      • ポート/ポート範囲: 5445
      • 送信先 IP アドレス: 10.1.1.2
      • ポート/ポート範囲: 5445
      TAB キーを使用して OK ボタンに移動し、ENTER を押します。
    10. TAB キーを使用して Close ボタンに移動し、ENTER を押します。
    11. TAB キーを使用して OK ボタンに移動し、ENTER を押します。変更内容を適用するには、警告を読み、Yes をクリックします。
  6. JBoss Enterprise Application Platform 6 ホストでファイアウォールを設定します。

    一部の組織では、JBoss Enterprise Application Platform 6 サーバー自体でファイアウォールを設定し、運用に必要ないすべてのポートを閉じます。「JBoss Enterprise Application Platform 6 により使用されるネットワークポート」 を参照して開くポートを決定し、残りのポートを閉じます。Red Hat Enterprise Linux 6 のデフォルトの設定では、22 (Secure Shell (SSH) 用) と 5353 (マルチキャスト DNS 用) 以外のすべてのポートが閉じられます。ポートを設定する場合は、間違ってロックアウトされないよう物理的にアクセスしてください。
結果

ファイアウォールが、ファイアウォール設定で指定したように、内部 JBoss Enterprise Application Platform 6 サーバーにトラフィックを転送します。サーバーでファイアウォールを有効にした場合は、アプリケーションを実行するために必要なポート以外のすべてのポートが閉じられます。

9.8.4. JBoss Enterprise Application Platform 6 により使用されるネットワークポート

JBoss Enterprise Application Platform 6 のデフォルト設定で使用されるポートは複数の要因に依存します。
  • 管理対象ドメインまたはスタンドアロンサーバー設定のいずれを使用するか。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。

注記

数値ポートオフセットは、同じ物理サーバーで複数のサーバーを実行する場合にポートの競合を緩和するために設定できます。サーバーが数値ポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループに対するオフセットをデフォルトのポート番号に追加します。たとえば、ソケットバインディンググループの HTTP ポートは 8080 であり、サーバーは 100 のポートオフセットを使用し、その HTTP ポートは 8180 です。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

表9.2 デフォルトのソケットバインディングの参照

名前 ポート マルチキャストポート 詳細 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。 はい はい はい はい
http 8080 デプロイされた Web アプリケーションのデフォルトポート。 はい はい はい はい
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。 はい はい はい はい
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 はい はい いいえ いいえ
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。 はい はい いいえ いいえ
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでピア検出に使用されます。 はい いいえ はい いいえ
jgroups-mping 45700 マルチキャスト。HA クラスタでの初期メンバーシップを検出するために使用されます。 はい いいえ はい いいえ
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。 はい いいえ はい いいえ
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのユニキャストピア検出。 はい いいえ はい いいえ
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
messaging 5445 JMS サービス。 はい はい いいえ いいえ
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。 はい はい いいえ いいえ
messaging-throughput 5455 JMS Remoting により使用されます。 はい はい いいえ いいえ
mod_cluster 23364 JBoss Enterprise Application Platform と HTTP ロードバランサー間の通信に対するマルチキャストポート。 はい いいえ はい いいえ
osgi-http 8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。 はい はい はい はい
remoting 4447 リモート EJB の呼び出しに使用されます。 はい はい はい はい
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。 はい はい はい はい
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。 はい はい はい はい
管理ポート

ソケットバインディンググループ以外に、各ホストコントローラーは管理用にさらに 2 つのポートを開きます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API により使用されるポート

9.9. Java セキュリティマネージャー

9.9.1. Java Security Manager

Java Security Manager
Java Security Manager は、Java 仮想マシン (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行するコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager が有効な場合、Java API は安全でない可能性のある操作を行う前に Security Manager が承認するか確認します。
Security Manager はセキュリティポリシーを使用して該当するアクションを許可するか、拒否するかを決定します。
Security Policy
様々なコードのクラスに対する定義済みのパーミッションセット。Java Security Manager はアプリケーションが要求したアクションとこのセキュリティポリシーを比較します。ポリシーでアクションが許可された場合、Security Manager により、アクションの実行が許可されます。ポリシーによりアクションが許可されない場合、Security Manager はこのアクションを拒否します。セキュリティポリシーは、コードの場所やコードのシグネチャーを基にパーミッションを定義することができます。
使用する Security Manager やセキュリティポリシーは、Java 仮想マシンのオプションjava.security.managerjava.security.policy を使用して設定されます。

9.9.2. Java Security Manager 内での JBoss Enterprise Application Platform の実行

Java Security Manager ポリシーを指定するには、ブートストラッププロセス中にドメインまたはサーバーインスタンスに渡す Java オプションを編集する必要があります。このため、domain.sh スクリプトまたは standalone.sh スクリプトにパラメーターをオプションとして渡すことはできません。次の手順を実行すると、インスタンスが Java Security Manager ポリシー内で実行されるよう設定できます。

前提条件

  • この手順を実行する前に、Java Development Kit (JDK) に含まれる policytool コマンドを使用してセキュリティーポリシーを記述する必要があります。この手順では、ポリシーが EAP_HOME/bin/server.policy にあることを前提としています。
  • 設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。
複数のシステムにドメインメンバーが分散されている場合は、ドメインの各物理ホストまたはインスタンスに対して次の手順を実行してください。

手順9.9 タスク

  1. 設定ファイルを編集します。

    編集のために設定ファイルを開きます。このファイルは、管理対象ドメインを使用しているか、スタンドアロンサーバーを使用しているかに応じて、2 つの場所のいずれかに存在します。これは、サーバーまたはドメインを起動するために使用される実行可能ファイルではありません。
    • 管理対象ドメイン

      EAP_HOME/bin/domain.conf
    • スタンドアロンサーバー

      EAP_HOME/bin/standalone.conf
  2. ファイルの最後に Java オプションを追加します。

    以下の行をファイルの最後に追加します。-Djava.security.policy 値を変更してセキュリティーポリシーの場所を指定できます。改行をせず 1 つの行のみで指定する必要があります。デバッグレベルを指定して -Djava.security.debug を変更し、さらに多くの情報または少ない情報をログに記録できます。最も冗長なのは verbose is failure,access,policy です。
    JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"
    
    
  3. ドメインサーバーを起動します。

    ドメインまたはサーバーを通常どおり起動します。

9.9.3. Java Security Manager ポリシー

Java Security Manager はセキュリティポリシーを使用して該当するアクションを許可するか、拒否するかを決定します。
様々なコードのクラスに対する定義済みのパーミッションセット。Java Security Manager はアプリケーションが要求したアクションとこのセキュリティポリシーを比較します。ポリシーでアクションが許可された場合、Java Security Manager によりアクションの実行が許可されます。ポリシーによりアクションが拒否された場合、Java Security Manager はこのアクションを拒否します。セキュリティポリシーは、コードの場所やコードのシグネチャーを基にパーミッションを定義することができます。
使用する Java Security Manager やセキュリティポリシーは、Java 仮想マシンのオプションjava.security.managerjava.security.policy を使用して設定されます。

9.9.4. Java Security Manager ポリシーの記述

はじめに

ほとんどの JDK および JRE ディストリビューションには、Java Security Manager セキュリティーポリシーを作成および編集するための policytool という名前のアプリケーションが含まれます。policytool の詳細については、http://docs.oracle.com/javase/6/docs/technotes/tools/ を参照してください。

基本情報

セキュリティーポリシーは、次の設定要素から構成されます。

CodeBase
コードの元の URL の場所 (ホストとドメイン情報を除外)。このパラメーターはオプションです。
SignedBy
コードを署名するためにプライベートキーが使用された署名者を参照するキーストアで使用されたエイリアス。これは、単一値またはカンマ区切りの値リストになります。このパラメーターはオプションです。省略された場合は、署名があってもなくても Java Security Manager に影響はありません。
Principals
principal_type/principal_name ペアのリスト。これは、実行スレッドのプリンシパルセット内に存在する必要があります。Principals エントリはオプションです。省略された場合は、「任意のプリンシパル」を意味します。
Permissions
パーミッションは、コードに与えられるアクセスです。多くのパーミッションは、Java Enterprise Edition 6 (Java EE 6) 仕様の一部として提供されます。本書では、JBoss Enterprise Application Platform で提供される追加のパーミッションについてのみ説明します。

手順9.10 タスク

  1. policytool を起動します。

    policytool ツールを次のいずれかの方法で起動します。
    • Red Hat Enterprise Linux

      GUI またはコマンドプロンプトで、/usr/bin/policytool を実行します。
    • Microsoft Windows Server

      スタート メニューまたは Java インストールの bin\ から、policytool.exe を実行します。場所は異なることがあります。
  2. 新しいポリシーを作成します。

    新しいポリシーを作成するには、Add Policy Entry を選択します。必要なパラメーターを追加し、Done をクリックします。
  3. 既存のポリシーの編集

    既存のポリシーのリストからポリシーを選択し、Edit Policy Entry ボタンを選択します。必要に応じて、パラメーターを編集します。
  4. 既存のポリシーを削除します。

    既存のポリシーのリストからポリシーを選択し、Delete Policy Entry ボタンを選択します。

JBoss Enterprise Application Platform に固有なパーミッション

org.jboss.security.SecurityAssociation.getPrincipalInfo
org.jboss.security.SecurityAssociation メソッドと getPrincipal() and getCredential() メソッドにアクセスを提供します。このランタイムパーミッションを使用する危険は、現在のスレッド呼び出し元とクレデンシャルを見ることができることです。
org.jboss.security.SecurityAssociation.getSubject
org.jboss.security.SecurityAssociationgetSubject() メソッドにアクセスを提供します。
org.jboss.security.SecurityAssociation.setPrincipalInfo
org.jboss.security.SecurityAssociationsetPrincipal() メソッド、setCredential(), setSubject() メソッド、pushSubjectContext() メソッド、および popSubjectContext() メソッドにアクセスを提供します。このランタイムパーミッションを使用する危険は、現在のスレッド呼び出し元とクレデンシャルを設定できることです。
org.jboss.security.SecurityAssociation.setServer
org.jboss.security.SecurityAssociationsetServer メソッドにアクセスを提供します。このランタイムパーミッションを使用する危険は、呼び出し元プリンシパルとクレデンシャルのマルチスレッドストレージを有効または無効にできることです。
org.jboss.security.SecurityAssociation.setRunAsRole
org.jboss.security.SecurityAssociationpushRunAsRole メソッド、popRunAsRole メソッド, pushRunAsIdentity メソッド、および popRunAsIdentity メソッドにアクセスを提供します。このランタイムパーミッションを使用する危険は、現在の呼び出し元の run-as ロールプリンシパルを変更できることです。
org.jboss.security.SecurityAssociation.accessContextInfo
org.jboss.security.SecurityAssociationaccessContextInfo および accessContextInfo の getter および setter メソッドにアクセスを提供します。これにより、現在のセキュリティーコンテキスト情報を設定および取得できます。
org.jboss.naming.JndiPermission
特別なパーミッションを、指定された JNDI ツリーパスのファイルおよびディレクトリーに提供するか、またはすべてのファイルとディレクトリーに対して再帰的に提供しjます。JndiPermission は、ファイルまたはディレクトリーに関連するパス名および有効なパーミッションセットから構成されます。
利用可能なパーミッションには以下のものがあります。
  • bind
  • rebind
  • unbind
  • lookup
  • list
  • listBindings
  • createSubcontext
  • all
/* で終わるパス名は、指定されたパーミッションがパス名のすべてのファイルとディレクトリーに適用されることを示します。/- で終わるパス名は、パス名のすべてのファイルとサブディレクトリーに対する再帰的なパーミッションを示します。パス名は、任意のディレクトリーの任意のファイルに一致する特別なトークン <<ALL BINDINGS>> から構成されます。
org.jboss.security.srp.SRPPermission
プライベートセッションキーやプライベートキーなどの機密性の高い SRP 情報へのアクセスを保護するカスタムパーミッションクラス。getSessionKey ターゲットは、SRP ネゴシエーションの結果得られるプライベートセッションへのアクセスを提供します。このキーへのアクセスでは、セッションキーで暗号化されたメッセージを暗号化および復号化できます。
org.hibernate.secure.HibernatePermission
このパーミッションクラスは、Hibernate セッションをセキュアにする基本的なパーミッションを提供します。このプロパティーのターゲットはエンティティー名です。利用可能なアクセスには以下のものがあります。
  • insert
  • delete
  • update
  • read
  • * (all)
org.jboss.metadata.spi.stack.MetaDataStackPermission
読み出し元がメタデータスタックと対話する方法を制御するカスタムパーミッションクラスを提供します。利用可能なパーミッションは以下のとおりです。
  • modify
  • push (スタックに対する)
  • pop (スタックから)
  • peek (スタックに対する)
  • * (all)
org.jboss.config.spi.ConfigurationPermission
設定プロパティーの設定をセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • <property name> (このコードが設定するパーミッションを持つプロパティー)
  • * (すべてのプロパティー)
org.jboss.kernel.KernelPermission
カーネル設定へのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • access (カーネル設定に対する)
  • 設定 (アクセスを暗黙的に)
  • * (all)
org.jboss.kernel.plugins.util.KernelLocatorPermission
カーネルへのアクセスをセキュアにします。パーミッションターゲット名のみを定義し、アクションを定義しません。このプロパティーのターゲットには以下のものが含まれます。
  • kernel
  • * (all)

9.9.5. Security Manager ポリシーのデバッグ

デバッグ情報を有効にすると、セキュリティーポリシーに関する問題のトラブルシューティングに便利です。java.security.debug オプションは、報告されたセキュリティー関連情報のレベルを設定します。コマンド java -Djava.security.debug=help は、すべてのデバッグオプションのヘルプ出力を表示します。デバッグレベルを all に設定すると、原因がまったくわからないセキュリティー関連の障害をトラブルシューティングするときに役に立ちますが、一般的な使用には多すぎる量の情報が表示されます。一般的に適切なデフォルト値は access:failure です。

手順9.11 一般的なデバッグの有効化

  • この手順を実行すると、セキュリティー関連デバッグ情報の一般的な機密レベルを有効にすることができます。

    次の行をサーバー設定ファイルに追加します。
    • 管理対象ドメインで JBoss Enterprise Application Platform インスタンスが実行されている場合、以下の行は Linux では bin/domain.conf ファイル、Windows では bin/domain.conf.bat ファイルに追加されます。
    • JBoss Enterprise Application Platform インスタンスがスタンドアロンサーバーとして実行されている場合、以下の行は Linux では bin/standalone.conf ファイル、Windows では bin\standalone.conf.bat ファイルに追加されます。
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows
JAVA_OPTS="%JAVA_OPTS% -Djava.security.debug=access:failure"
結果

セキュリティー関連デバッグ情報の一般的なレベルが有効になります。

9.10. アプリケーションのセキュリティー

9.10.1. 記述子ベースのプロパティー置換の有効化/無効化

概要

記述子プロパティー置換の有限制御が、jboss-as-ee_1_1.xsd に導入されました。このタスクには、記述子ベースのプロパティー置換を設定するのに必要な手順が含まれます。

記述子ベースのプロパティー置換フラグはブール値を持ちます。
  • true に設定された場合は、プロパティー置換が有効になります。
  • false に設定された場合は、プロパティー置換が無効になります。

手順9.12 jboss-descriptor-property-replacement

jboss-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
jboss-descriptor-property-replacement のデフォルト値は true です。
  1. 管理 CLI では、次のコマンドを実行して jboss-descriptor-property-replacement の値を決定します。
    /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

手順9.13 spec-descriptor-property-replacement

spec-descriptor-property-replacement は、次の記述子でプロパティー置換を有効または無効にするために使用されます。
  • ejb-jar.xml
  • persistence.xml
spec-descriptor-property-replacement のデフォルト値は false です。
  1. 管理 CLI では、次のコマンドを実行して spec-descriptor-property-replacement の値を確認します。
    /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
結果

記述子ベースのプロパティー置換が正常に設定されます。

9.11. 機密性の高い文字列のパスワードボールト

9.11.1. クリアテキストファイルでの機密性が高い文字列のセキュア化について

Web アプリケーションと他のデプロイメントには、パスワードや他の機密性が高い文字列のような機密性が高い情報を含む XML デプロイメント記述子などのクリアテキストファイルが含まれることがよくあります。JBoss Enterprise Application Platform には、機密性が高い文字列を暗号化し、暗号化キーストアに格納できるパスワード vault メカニズムが含まれます。vault メカニズムは、セキュリティードメイン、セキュリティー領域、または他の検証システムで使用する文字列の復号化を管理します。これにより、セキュリティーのレイヤーが追加されます。このメカニズムは、サポートされるすべての Java Development Kit (JDK) 実装に含まれるツールに依存します。

9.11.2. 機密性が高い文字列を格納する Java キーストアの作成

前提条件

  • keytool コマンドを使用出来る必要があります。これは Java Runtime Environment (JRE) により提供されます。このファイルのパスを見つけます。Red Hat Enterprise Linux では、これは /usr/bin/keytool にインストールされます。

手順9.14 タスク

  1. キーストアと他の暗号化された情報を格納するディレクトリーを作成します。

    キーストアと他の重要な情報を保持するディレクトリーを作成します。この残りの手順では、ディレクトリーが /home/USER/vault/ であることを前提とします。
  2. keytool で使用するパラメーターを決定します。

    以下のパラメーターを決定します。
    alias
    エイリアスは資格情報コンテナまたはキーストアに格納された他のデータの一意の ID です。この手順の最後にあるコマンド例のエイリアスは vault です。エイリアスは大文字と小文字を区別します。
    keyalg
    暗号化に使用するアルゴリズム。デフォルト値は DSA です。この手順の例では RSA です。利用可能な他の選択肢については、JRE およびオペレーティングシステムのドキュメンテーションを参照してください。
    keysize
    暗号化キーのサイズにより、ブルート フォース攻撃により復号化する困難さが影響を受けます。キーのデフォルトサイズは 1024 です。これは 512 〜 1024 の範囲にあり、64 の倍数である必要があります。この手順の例では 1024 を使用します。
    keystore
    暗号化された情報と暗号化方法に関する情報を保持するデータベースのキーストア。キーストアを指定しない場合、使用するデフォルトのキーストアはホームディレクトリーの .keystore という名前のファイルです。これは、キーストアにデータを初めて追加したときに作成されます。この手順の例では、vault.keystore キーストアを使用します。
    keystore コマンドには他の多くのオプションがあります。詳細については、JRE またはオペレーティングシステムのドキュメンテーションを参照してください。
  3. keystore コマンドが尋ねる質問の回答を決定します。

    keystore は、キーストアエントリに値を入力するために次の情報を必要とします。
    キーストアパスワード
    キーストアを作成する場合は、パスワードを設定する必要があります。将来キーストアを使用するために、パスワードを提供する必要があります。覚えやすい強度の高いパスワードを作成します。キーストアは、パスワードや、キーストアが存在するファイルシステムおよびオペレーティングシステムのセキュリティーと同程度にセキュアです。
    キーパスワード (任意設定)
    キーストアパスワードに加え、保持する各キーにパスワードを指定することが可能です。このようなキーを使用するには、使用するたびにパスワードを提供する必要があります。通常、このファシリティーは使用されません。
    名前 (名) と 名字 (姓)
    この情報と一覧の他の情報は、一意にキーを識別して他のキーの階層に置くのに役立ちます。名前である必要はありませんが、キーに一意な 2 つの言葉である必要があります。この手順の例では、Enterprise Application Platform Vault を使用します。これが証明書のコモンネームになります。
    組織単位
    証明書を使用する人物を特定する単一の言葉です。アプリケーションユニットやビジネスユニットである場合もあります。この手順の例では enterprise_application_platform を使用します。通常、1 つのグループやアプリケーションによって使用されるキーストアはすべて同じ組織単位を使用します。
    組織
    通常、所属する組織名を表す単一の言葉になります。一般的に、1 つの組織で使用されるすべての証明書で同じになります。この例では acme を使用します。
    市または自治体
    お住まいの市名。
    州または県
    お住まいの州や県、または同等の行政区画
    2 文字の国コード
    これらすべての情報によってキーストアや証明書の階層が作成され、一貫性のある一意な名前付け構造が確実に使用されるようにします。
  4. keytool コマンドを実行し、収集した情報を提供します。

    例9.25 keystore コマンドの入出力例

    $ keytool -genkey -alias vault -keyalg RSA -keysize 1024 -keystore /home/USER/vault/vault.keystore
    Enter keystore password: vault22 
    Re-enter new password:vault22 
    What is your first and last name?
      [Unknown]:  Enterprise Application Platform vault
    What is the name of your organizational unit?
      [Unknown]:  enterprise_application_platform
    What is the name of your organization?
      [Unknown]:  acme
    What is the name of your City or Locality?
      [Unknown]:  raleigh
    What is the name of your State or Province?
      [Unknown]:  nc
    What is the two-letter country code for this unit?
      [Unknown]:  us
    Is CN=Enterprise Application Platform vault, OU=enterprise_application_platform, O=acme, L=raleigh, ST=nc, C=us correct?
      [no]:  yes
    
    Enter key password for <vault>
            (RETURN if same as keystore password):
    
結果

/home/USER/vault/ ディレクトリに vault.keystore という名前のファイルが作成されます。Enterprise Application Platform のパスワードなど、暗号化された文字列を格納するため使用される vault という 1 つのキーがこのファイルに保存されます。

9.11.3. キーストアパスワードのマスキングとパスワード vault の初期化

要件

  1. vault.sh コマンドを実行します。

    EAP_HOME/bin/vault.sh を実行します。0 を入力して新しい対話セッションを開始します。
  2. 暗号化されたファイルが保存されるディレクトリを入力します。

    このディレクトリはある程度保護されている必要がありますが、JBoss Enterprise Application Platform がアクセスできなければなりません。「機密性が高い文字列を格納する Java キーストアの作成」 の手順に従うと、キーストアはホームディレクトリにある vault/ というディレクトリの中にあります。この例では /home/USER/vault/ を使用します。

    注記

    必ずディレクトリ名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて / または \ を使用します。
  3. キーストアへのパスを入力します。

    キーストアファイルへの完全パスを入力します。この例では /home/USER/vault/vault.keystore を使用します。
  4. キーストアパスワードを暗号化します。

    次の手順に従って、設定ファイルやアプリケーションで安全に使用できるようキーストアのパスワードを暗号化します。
    1. キーストアパスワードを入力します。

      入力を促されたらキーストアのパスワードを入力します。
    2. salt 値を入力します。

      8 文字の salt 値を入力します。salt 値は反復回数(下記) と共にハッシュ値の作成に使用されます。
    3. 反復回数を入力します。

      反復回数の値を入力します。
    4. マスクされたパスワード情報を書き留めておきます。

      マスクされたパスワード と salt、反復回数は標準出力へ書き出されます。これらの情報を安全な場所に書き留めておきます。攻撃者がこれらの情報を使用してパスワードを復号化する可能性があるからです。
    5. vault のエイリアスを入力します。

      入力を促されたら、vault のエイリアスを入力します。「機密性が高い文字列を格納する Java キーストアの作成」 に従って vault を作成した場合、エイリアスは vault になります。
  5. 対話コンソールを終了します。

    exit を入力して対話コンソールを終了します。
結果

設定ファイルとデプロイメントで使用するため、キーストアパスワードがマスキングされます。また、vault が完全設定され、すぐ使用できる状態になります。

9.11.4. パスワード vault を使用するよう Enterprise Application Platform を設定する

概要

設定ファイルにあるパスワードや機密性の高いその他の属性をマスキングする前に、これらを保存し復号化するパスワード vault を Enterprise Application Platform が認識するようにする必要があります。現在、この作業を行うには Enterprise Application Platform を停止し、設定を直接編集する必要があります。

前提条件

手順9.15 タスク

  1. テキストエディターで設定ファイルを開きます。

    Enterprise Application Platform が停止した後、エディターで設定ファイルを開きます。デフォルトの設定ファイルへのパスは次の 1 つになります。
    • 管理ドメイン - EAP_HOME/domain/configuration/domain.xml
    • スタンドアローンサーバー - EAP_HOME/standalone/configuration/standalone.xml
  2. ボールト設定を挿入します。

    extensions section: </extensions> の end-tag を探し、その下に次のコードを張り付けます。以下の値は 「機密性が高い文字列を格納する Java キーストアの作成」「キーストアパスワードのマスキングとパスワード vault の初期化」 の独自の値に置き換えます。
    <vault>
      <vault-option name="KEYSTORE_URL" 
                    value="/home/<replaceable>USER</replaceable>/vault/vault.keystore"/>
      <vault-option name="KEYSTORE_PASSWORD" value="MASK-3y28rCZlcKR"/>
      <vault-option name="KEYSTORE_ALIAS" value="vault"/>
      <vault-option name="SALT" value="12438567"/>
      <vault-option name="ITERATION_COUNT" value="50"/>
      <vault-option name="ENC_FILE_DIR" value="${user.home}/vault/"/>
    </vault>	  
    
    
  3. Enterprise Application Platform を再起動します。

    ファイルを保存してから終了し、Enterprise Application Platform を再起動します。
結果

パスワード vault を使用してマスキングされた文字列を復号化するよう Enterprise Application Platform が設定されます。ボールトに文字列を追加し、設定で使用する場合は 「Java キーストアに暗号化された機密性の高い文字列を保存し読み出しする」 を参照してください。

9.11.5. Java キーストアに暗号化された機密性の高い文字列を保存し読み出しする

概要

パスワードや機密性の高いその他の文字列が平文の設定ファイルに含まれるのは安全ではありません。Enterprise Application Platform には、このような機密性の高い文字列をマスキングして暗号化されたキーストアに保存する機能や、設定ファイルでマスクされた値を使用する機能が含まれています。

手順9.16 タスク

  1. vault.sh コマンドを実行します。

    EAP_HOME/bin/util/vault.sh を実行します。0 を入力して新しい対話セッションを開始します。
  2. 暗号化されたファイルが保存されるディレクトリを入力します。

    「機密性が高い文字列を格納する Java キーストアの作成」 に従って作業を行った場合はキーストアはホームディレクトリの vault/ というディレクトリにあります。ほとんどの場合では、暗号化されたすべての情報をキーストアとして同じ場所に保存するのが普通です。この例では /home/USER/vault/ ディレクトリを使用します。

    注記

    必ずディレクトリ名の最後にスラッシュが含まれるようにしてください。ご使用のオペレーティングシステムに応じて / または \ を使用します。
  3. キーストアへのパスを入力します。

    キーストアファイルへの完全パスを入力します。この例では /home/USER/vault/vault.keystore を使用します。
  4. キーストアパスワード、ボールト名、ソルト、反復回数を入力します。

    入力を促されたら、キーストアパスワード、ボールト名、ソルト、反復回数を入力します。ハンドシェイクが実行されます。
  5. パスワードを保存するオプションを選択します。

    オプション 0 を選択して、パスワードや機密性の高い他の文字列を保存します。
  6. 値を入力します。

    入力を促されたら、値を 2 回入力します。値が一致しない場合は再度入力するよう要求されます。
  7. ボールトブロックを入力します。

    同じリソースに関連する属性のコンテナであるボールトブロックを入力します。属性名の例としては ds_ExampleDS などが挙げられます。データソースまたは他のサービス定義で、暗号化された文字列への参照の一部を形成します。
  8. 属性名を入力します。

    保存する属性の名前を入力します。 password が属性名の例の 1 つになります。
    結果

    以下のようなメッセージが属性が保存されたことを示します。

    Attribute Value for (ds_ExampleDS, password) saved
  9. 暗号化された文字列に関する情報を書き留めます。

    メッセージはボールトブロック、属性名、共有キー、設定で文字列を使用する場合のアドバイスを示す標準出力を出力します。安全な場所にこの情報を書き留めておいてください。出力例は次の通りです。
    ********************************************
    Vault Block:ds_ExampleDS
    Attribute Name:password
    Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
    Configuration should be done as follows:
    VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
    ********************************************
    
  10. 設定で暗号化された文字列を使用します。

    プレーンテキストの文字列の代わりに前の設定手順の文字列を使用します。上記の暗号化されたパスワードを使用するデータソースが以下に示されています。
    ...
      <subsystem xmlns="urn:jboss:domain:datasources:1.0">
        <datasources>
          <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
            <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
            <driver>h2</driver>
            <pool></pool>
            <security>
              <user-name>sa</user-name>
              <password>VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0</password>
            </security>
          </datasource>
          <drivers>
             <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
             </driver>
          </drivers>
        </datasources>
      </subsystem>
    ...
    
    
    ドメインまたはスタンドアローン設定ファイルのどこにでも暗号化された文字列を使用することができます。文字列をキーストアに保存した後、次の構文を使用してクリアテキストの文字列を暗号化された文字列に置き換えます。
    ${VAULT::<replaceable>VAULT_BLOCK</replaceable>::<replaceable>ATTRIBUTE_NAME</replaceable>::<replaceable>ENCRYPTED_VALUE</replaceable>
    
    実環境の値の例は次の通りです。ボールトブロックは ds_ExampleDS、属性は password です。
    <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
    

9.11.6. アプリケーションで機密性の高い文字列を保存し解決する

概要

Enterprise Application Platform の設定要素は、セキュリティーボールトメカニズムを通じて Java キーストアに保存される値に対して暗号化された文字列を解決する機能をサポートしています。この機能に対するサポートを独自のアプリケーションに追加することができます。

最初に、ボールトにパスワードを追加します。次に、クリアテキストのパスワードをボールトに保存されているパスワードに置き換えます。この方法を使用してアプリケーションの機密性の高い文字列を分かりにくくすることができます。
前提条件

この手順を実行する前に、ボールトファイルを格納するディレクトリが存在することを確認してください。JBoss Enterprise Application Platform を実行するユーザーがボールトファイルを読み書きできるパーミッションを持っていれば、ボールトファイルの場所はどこでも構いません。この例では、vault/ ディレクトリを /home/USER/vault/ ディレクトリに置きます。ボールト自体は vault/ ディレクトリの中にある vault.keystore と呼ばれるファイルになります。

例9.26 ボールトへパスワードの文字列を追加する

EAP_HOME/bin/vault.sh コマンドを用いて文字列をボールトへ追加します。次のセッションに完全セッションが含まれています。ユーザー入力の値は強調文字で表されています。出力の一部は書式設定のため削除されています。Microsoft Windows ではコマンド名は vault.bat になります。Microsoft Windows のファイルパスでは、/ ではなく \ 文字がディレクトリの分離記号として使用されることに注意してください。
[user@host bin]$ ./vault.sh 
**********************************
****  JBoss Vault ********
**********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:/home/user/vault/
Enter Keystore URL:/home/user/vault/vault.keystore
Enter Keystore password: ...
Enter Keystore password again: ...
Values match
Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):25

Enter Keystore Alias:vault
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
0
Task:  Store a password
Please enter attribute value: sa
Please enter attribute value again: sa
Values match
Enter Vault Block:DS
Enter Attribute Name:thePass
Attribute Value for (DS, thePass) saved

Please make note of the following:
********************************************
Vault Block:DS
Attribute Name:thePass
Shared Key:OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0
Configuration should be done as follows:
VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0
********************************************

Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
2
Java コードに追加される文字列は、出力の最後の値である VAULT で始まる行です。
次のサーブレットは、クリアテキストのパスワードの代わりにボールトされた文字列を使用します。違いを確認できるようにするため、クリアテキストのパスワードはコメントアウトされています。

例9.27 ボールトされたパスワードを使用するサーブレット

package vaulterror.web;
 
import java.io.IOException;
import java.io.Writer;
 
import javax.annotation.Resource;
import javax.annotation.sql.DataSourceDefinition;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
 
 
/*@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "sa",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)*/
@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "VAULT::DS::thePass::OWY5M2I5NzctYzdkOS00MmZhLWExZGYtNjczM2U5ZGUyOWIxTElORV9CUkVBS3ZhdWx0",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
@WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1)
public class MyTestServlet  extends HttpServlet {
 
    private static final long serialVersionUID = 1L;
 
 
    @Resource(lookup = "java:jboss/datasources/LoginDS")
    private DataSource ds;
 
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        Writer writer = resp.getWriter();
        writer.write((ds != null) + "");
    }
}
これでサーブレットがボールトされた文字列を解決できるようになります。

第10章 セキュリティー管理リファレンス

10.1. 含まれる認証モジュール

以下の認証モジュールが Enterprise Application Platform に含まれます。これらの一部は許可と認証を処理します。これらでは、通常単語 RoleCode 名に含まれます。
これらのモジュールを設定する場合は、モジュールを参照するために Code 値を使用します。

表10.1 クライアント

コード クライアント
クラス
org.jboss.security.ClientLoginModule
詳細
このログインモジュールは、Enterprise Application Platform がクライアントと対話するときに呼び出し元 ID とクレデンシャルを確立するよう設定されています。これは、実際のサーバー認証に使用されるセキュリティードメインの一部として使用しないでください。

表10.2 クライアントモジュールオプション

オプション タイプ デフォルト 詳細
マルチスレッド ブール値
false
各スレッドが独自のプリンシパルとクレデンシャルストレージを持つ場合は、true に設定します。VM 内のすべてのスレッドが同じ ID とクレデンシャルを共有するよう指定する場合は false に設定します。
password-stacking
useFirstPass または false
false
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
restore-login-identity ブール値
false
() メソッドの先頭に示された ID とクレデンシャルを logout() メソッドの呼び出し後に復元する必要がある場合は true に設定します。

表10.3 証明書

コード 証明書
クラス
org.jboss.security.auth.spi.BaseCertLoginModule
詳細
このログインモジュールは、X509 証明書に基づいてユーザーを認証するよう設計されています。この使用例は、Web アプリケーションの CLIENT-CERT 認証です。

表10.4 証明書モジュールオプション

オプション タイプ デフォルト 詳細
securityDomain 文字列
信頼済み証明書を保持するトラストストア用 JSSE 設定を持つセキュリティードメインの名前。
verifier クラス
ログイン証明書の検証に使用する org.jboss.security.auth.certs.X509CertificateVerifier のクラス名。

表10.5 CertificateUsers

コード CertificateUsers
クラス
org.jboss.security.auth.spi.UsersRolesLoginModule
詳細
ユーザー名とパスワード、ユーザー名とロールをそれぞれマップするために 2 つのプロパティーリソースを使用します。

表10.6 CertificateUsers モジュールオプション

オプション タイプ デフォルト 詳細
unauthenticatedIdentity 文字列
認証情報を含まない要求に割り当てる必要があるプリンシパル名を定義します。これにより、保護されていないサーブレットは特定のロールを必要としない EJB でメソッドを呼び出すことができるようになります。このようなプリンシパルでは、ロールが割り当てられず、unchecked permission 制約に関連付けられたセキュアでない EJB または EJB メソッドにのみアクセスできます。
password-stacking
useFirstPass または false
false
このログインモジュールが ID として使用する LoginContext に格納された情報を探すよう指定する場合は、useFirstPass に設定します。このオプションは、他のログインモジュールをスタックする場合に使用できます。
hashAlgorithm 文字列
パスワードをハッシュ化するために使用する java.security.MessageDigest アルゴリズムの名前。デフォルト値はないため、ハッシュを有効にするためにこのオプションを明示的に設定する必要があります。hashAlgorithm が指定された場合は、inputPassword 引数として UsernamePasswordLoginModule.validatePassword に渡す前に CallbackHandler から取得されたクリアテキストパスワードがハッシュ化されます。users.properties ファイルに格納された expectedPassword も、同様にハッシュ化する必要があります。
hashEncoding
base64 または hex
base64
ハッシュ化されたパスワードの文字列形式 (hashAlgorithm も設定された場合)。
hashCharSet 文字列
コンテナーの環境で設定されたデフォルトエンコーディング
クリアテキストパスワードをバイトアレイに変換するために使用されるエンコーディング。
usersProperties
プロパティーファイルまたはリソース
users.properties
ユーザーとパスワード間のマッピングを含むファイル。ファイルの各プロパティーの形式は username=password です。
rolesProperties プロパティーファイルまたはリソース
roles.properties
ユーザーとロール間のマッピングを含むファイル。ファイルの各プロパティーの形式は username=role1,role2,...,roleN です。
ignorePasswordCase ブール値
false
パスワード比較で大文字と小文字の区別を無視するかどうか。これは、ハッシュ化されたパスワードが大文字であるか小文字であるかが重要でない、ハッシュ化パスワードエンコーディングの場合に役に立ちます。
principalClass クラス
プリンシパル名として String 引数を取るコンストラクターを含む Principal 実装クラス。
roleGroupSeparator
単一の文字
. (単一の期間)
rolesGroup ファイルでユーザー名とロールグループ名を区別するために使用される文字。
defaultUsersProperties 文字列
defaultUsers.properties
使用するリソースまたはファイルの名前 (usersProperties ファイルが見つからない場合)。
defaultRolesProperties 文字列
defaultRoles.properties
使用するリソースまたはファイルの名前 (rolesProperties ファイルが見つからない場合)。
hashUserPassword ブール値
true
ユーザーが入力したパスワードをハッシュ化するかどうか (hashAlgorithm が指定された場合)。デフォルトで true に設定されます。
hashStorePassword ブール値
true
getUsersPassword() から返されたストアパスワードをハッシュ化するかどうか (hashAlgorithm が指定された場合)。
digestCallback classname
ソルト値などのプレ/ポストダイジェストコンテンツを含む org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashAlgorithm が指定された場合にのみ使用されます。
storeDigestCallback classname
ストアパスワードをハッシュ化するソルト値などのプレ/ポストダイジェストコンテンツを含む org.jboss.crypto.digest.DigestCallback 実装のクラス名。hashStorePassword が true であり、hashAlgorithm が指定された場合にのみ使用されます。
callback.option... なし なし
callback.option. の前に指定されたすべてのオプションは、DigestCallback.init(Map) メソッドに渡されます。入力されたユーザー名は、常に javax.security.auth.login.name オプションを介して渡され、入力/ストアパスワードは、javax.security.auth.login.password オプションを介して digestCallback または storeDigestCallback に渡されます。

表10.7 CertificateRoles

コード CertificateRoles
クラス
org.jboss.security.auth.spi.CertRolesLoginModule
詳細
このログインモジュールは、Certificate ログインモジュールを拡張して、プロパティーファイルからロールマッピング機能を追加します。同じすべてのオプションを Certificate ログインモジュールとして取得し、これらのオプションを追加します。

表10.8 CertificateRoles モジュールオプション

オプション タイプ デフォルト 詳細
rolesProperties 文字列
roles.properties
各ユーザーに割り当てるロールを含むリソースまたはファイルの名前。ロールプロパティーファイルの形式は username=role1,role2 である必要があります。ここで、username は、証明書の DN であり、すべての等記号やスペース文字をエスケープします。次の例が正しい形式です。
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US=JBossAdmin
defaultRolesProperties 文字列
defaultRoles.properties
rolesProperties ファイルが見つからない場合に使用するリソースまたはファイルの名前。
roleGroupSeparator 単一の文字
. (単一の期間)
ロールプロパティーファイルでどの文字をロールグループセパレーターとして使用するか。

表10.9 データベース

コード データベース
クラス
org.jboss.security.auth.spi.DatabaseServerLoginModule
詳細
認証とロールマッピングをサポートする JDBC ベースのログインモジュール。これは、次の定義を使用して、2 つの論理テーブルに基づきます。
  • Principals: PrincipalID (text), Password (text)
  • Roles: PrincipalID (text), Role (text), RoleGroup (text)

表10.10 データベースモジュールオプション

オプション タイプ デフォルト 詳細
dsJndiName JNDI リソース
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
principalsQuery SQL ステートメント
select Password from Principals where PrincipalID=?
プリンシパルに関する情報を取得するために準備された SQL クエリー。
rolesQuery SQL ステートメント
select Role, RoleGroup from Roles where PrincipalID=?
ロールに関する情報を取得するために準備された SQL クエリー。

表10.11 DatabaseCertificate

コード DatabaseCertificate
クラス
org.jboss.security.auth.spi.DatabaseCertLoginModule
詳細
このログインモジュールは、Certificate ログインモジュールを拡張して、データベーステーブルからロールマッピング機能を追加します。同じオプションと次の追加オプションが存在します。

表10.12 DatabaseCertificate モジュールオプション

オプション タイプ デフォルト 詳細
dsJndiName JNDI リソース
認証情報を保持する JNDI リソースの名前。このオプションは必須です。
rolesQuery SQL ステートメント
select Role,RoleGroup from Roles where PrincipalID=?
ロールをマップするために実行される SQL 準備ステートメント。これは、select Role, RoleGroup from Roles where PrincipalID=? と同じである必要があります。ここで、Role はロール名であり、RoleGroup 列の値は常に R が大文字である Roles. である必要があります。
suspendResume ブール値
true
データベース操作中に既存の JTA トランザクションを一時停止するかどうか。

表10.13 Identity

コード Identity
クラス
org.jboss.security.auth.spi.IdentityLoginModule
詳細
モジュールオプションで指定されたプリンシパルをモジュールに対して認証されたサブジェクトと関連付けます。使用される Principal クラスのタイプは org.jboss.security.SimplePrincipal. です。プリンシパルオプションが指定されない場合は、名前が guest のプリンシパルが使用されます。

表10.14 Identity モジュールオプション

オプション タイプ デフォルト 詳細
プリンシパル 文字列
guest
プリンシパルに使用する名前。
ロール カンマ区切りの文字列リスト
サブジェクトに割り当てられるロールのカンマ区切りリスト。

表10.15 Ldap

コード Ldap
クラス
org.jboss.security.auth.spi.LdapLoginModule
詳細
ユーザー名とパスワードが、JNDI LDAP プロバイダーを使用してアクセスできる LDAP サーバーに格納された場合に、LDAP サーバーに対して認証します。多くのオプションは、LDAP プロバイダーまたは環境によって決定されるため、必須ではありません。

表10.16 Ldap モジュールオプション

オプション タイプ デフォルト 詳細
java.naming.factory.initial クラス名
com.sun.jndi.ldap.LdapCtxFactory
InitialContextFactory 実装クラス名。
java.naming.provider.url
ldap:// URL
####
LDAP サーバー用 URL。
java.naming.security.authentication
nonesimple、または SASL メカニズムの名前
simple
LDAP サーバーにバインドするために使用するセキュリティーレベル。
java.naming.security.protocol トランスポートプロトコル
指定されない場合は、プロバイダーによって決定されます。
SSL などの、セキュアアクセスに使用するトランスポートプロトコル。
java.naming.security.principal 文字列
サービスに対する呼び出し元を認証するプリンシパルの名前。これは、以下に示された他のプロパティーから構築されます。
java.naming.security.credentials クレデンシャルタイプ
認証スキームにより使用されるクレデンシャルのタイプ。一部の例には、ハッシュ化されたパスワード、クリアテキストパスワード、キー、または証明書が含まれます。このプロパティーが指定されない場合は、動作がサービスプロバイダーにより決定されます。
principalDNPrefix 文字列
ユーザー DN を形成するユーザー名に追加されるプレフィックス。ユーザーにユーザー名の指定を要求したり、principalDNPrefix と principalDNSuffix を使用して完全修飾 DN を構築したりできます。
principalDNSuffix 文字列
ユーザー DN を形成するユーザー名に追加されるサフィックス。ユーザーにユーザー名の指定を要求したり、principalDNPrefix と principalDNSuffix を使用して完全修飾 DN を構築したりできます。
useObjectCredential ブール値
JAAS PasswordCallback を使用した char[] パスワードではなく Callback の org.jboss.security.auth.callback.ObjectCallback タイプを使用した不透明なオブジェクトとしてクレデンシャルを取得するかどうか。これにより、non-char[] クレデンシャル情報を LDAP サーバーに渡すことができるようになります。
rolesCtxDN 完全修飾 DN
ユーザーロールを検索するコンテキスト用完全修飾 DN。
userRolesCtxDNAttributeName 属性
ユーザーロールを検索するコンテキスト用 DN を含むユーザーオブジェクトの属性。これは、rolesCtxDN と異なるため、ユーザーのロールを検索するコンテキストは各ユーザーに対して一意になることがあります。
rolesAttributeID 属性
roles
ユーザーロールを含む属性の名前。
rolesAttributeIsDN ブール値
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、ロール名がコンテキスト名の roleNameAttributeId 属性の値から取得されます。Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
rolesNameAttributeID 属性
group
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
uidAttributeID 属性
uid
ユーザー ID に対応する UserRolesAttributeDN の属性の名前。これは、ユーザーロールを見つけるために使用されます。
matchOnUserDN ブール値
false
ユーザーロールの検索でユーザーの完全識別 DN またはユーザー名のみに一致するかどうか。true の場合、完全 userDN は一致する値として使用されます。false の場合は、ユーザー名のみが uidAttributeName 属性に対して一致する値として使用されます。
allowEmptyPasswords ブール値
true
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱われます。空のパスワードを拒否するには、これを false に設定します。

表10.17 LdapExtended

コード LdapExtended
クラス
org.jboss.security.auth.spi.LdapExtLoginModule
詳細
検索を使用してバインドユーザーと関連するロールを見つける別の LDAP ログインモジュール実装。ロールクエリーは再帰的に DN に従い、階層ロール構造をナビゲートします。同じ java.naming オプションを Ldap モジュールとして使用し、Ldap モジュールの他のオプションの代わりに次のオプションを使用します。
認証は 2 つのステップで行われます。
  1. LDAP サーバーに対する初期バインドは、bindDN および bindCredential オプションを使用して行われます。bindDN は、baseCtxDN および rolesCtxDN ツリーの両方でユーザーとロールを検索できるユーザーです。認証するユーザー DN は、baseFilter 属性で指定されたフィルターを使用して問い合わされます。
  2. 結果となるユーザー DN は、InitialLdapContext 環境 Context.SECURITY_PRINCIPAL としてユーザー DN を使用して LDAP サーバーにバインドすることにより認証されます。Context.SECURITY_CREDENTIALS プロパティーは、コールバックハンドラーにより取得された String パスワードに設定されます。

表10.18 LdapExtended モジュールオプション

オプション タイプ デフォルト 詳細
baseCtxDN 完全修飾 DN
ユーザー検索を開始する最上位コンテキストの固定 DN。
BindDN 完全修飾 DN
ユーザーおよびロールクエリーのために LDAP サーバーに対してバインドするために使用される DN。この DN は baseCtxDN および rolesCtxDN の値に対する読み取りおよび検索パーミッションを必要とします。
bindCredential 文字列、オプションで暗号化
bindDN のパスワード。これは、jaasSecurityDomain が指定された場合に暗号化できます。
jaasSecurityDomain JMX ObjectName
bindCredential を暗号化するために使用する JaasSecurityDomain の JMX ObjectName。パスワードの暗号化形式は、JaasSecurityDomain.encrypt64(byte[]) メソッドにより返された形式です。また、org.jboss.security.plugins.PBEUtils クラスを使用して暗号化形式を生成することもできます。
baseFilter LDAP フィルター文字列
認証するユーザーのコンテキストを見つけるために使用される検索フィルター。ログインモジュールコールバックから取得された入力ユーザー名/userDN が、{0} 式が使用されたフィルターに置換されます。検索フィルターの一般的な例は (uid={0}) です。
rolesCtxDN 完全修飾 DN
ユーザーロールを検索するコンテキストの固定 DN。これは、実際のロールが存在する DN ではなく、ユーザーロールを含むオブジェクトが存在する DN です。たとえば、Active Directory サーバーでは、これは、ユーザーアカウントが存在する DN です。
roleFilter LDAP フィルター文字列
認証済みユーザーと関連付けられたロールを検索するために使用される検索フィルター。ログインモジュールコールバックから取得された入力ユーザー名/userDN が {0} 式が使用されたフィルターに置換されます。認証済み userDN は、{1} が使用されたフィルターに置換されます。入力ユーザー名に一致する検索フィルター例は、(member={0}) です。認証済み userDN に一致する代わりの例は (member={1}) です。
roleAttributeIsDN ブール値
false
roleAttributeID にロールオブジェクトの完全修飾 DN が含まれるかどうか。false の場合は、ロール名がコンテキスト名の roleNameAttributeId 属性の値から取得されます。Active Directory などの特定のディレクトリースキーマでは、この属性を true に設定する必要があります。
roleNameAttributeID 属性
group
ロール名を含む roleCtxDN コンテキスト内の属性の名前。roleAttributeIsDN プロパティーが true に設定された場合、このプロパティーはロールオブジェクトの名前属性を見つけるために使用されます。
distinguishedNameAttribute 属性
distinguishedName
ユーザーの DN を含むユーザーエントリーの属性の名前。これは、ユーザー自身の DN に正しいユーザーマッピングを防ぐ特殊文字 (バックスラッシュなど) が含まれる場合に、必要になることがあります。属性が存在しない場合は、エントリーの DN が使用されます。
roleRecursion 整数
0
ロール検索が一致するコンテキストで行われる再帰のレベル数。再帰を無効にするには、これを 0 に設定します。
searchTimeLimit 整数
10000 (10 秒)
ユーザー/ロール検索のタイムアウト (ミリ秒単位)。
searchScope
次のいずれか: OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE
SUBTREE_SCOPE
使用する検索スコープ。
allowEmptyPasswords ブール値
true
空白のパスワードを許可するかどうか。ほとんどの LDAP サーバーでは、空白のパスワードが匿名ログイン試行として扱わ