木曜日 11 27, 2008

JavaES 5 U1 の Access Manager を Solaris 10 U6 上で Glassfish に配備する際の注意事項

今回は、JavaES 5 Update 1 の Access Manager (バージョン 7.1) を Solaris 10 Update 6 (Solaris 10 の最新のアップデートリリース) 上で、Glassfish に配備する際に注意すべきことについて書きたいと思います。

説明のために、具体的なシナリオとして、以下のような手順でインストール、設定、配備を行うことにします。

  • プラットフォームは、Solaris 10 U6 for x86(64 bit) とする。
  • まず、 Glassfish v2 Update release 2(Sun Java System Application Server 9.1 Update 2) をインストールする。
  • 次に、Sun Java System Directory Server Enterprise Edition version 6.3(以下 DSEE 6.3) をインストールする。
  • 最後に、JavaES 5 Update 1 のインストーラを用いて、同梱されている Access Manager 7.1 (以下 AM 7.1) をインストールし、amconfig コマンドを用いて、Glassfish に配備する。


1. Glassfish のインストール

Glassfish は、Sun download centerや、Glassfish のダウンロードページからダウンロードできます。
ダウンロードしたら、インストーラを起動して、画面の指示に従ってインストールを行ってください。 インストールが完了し、サーバーの起動を済ませたら、ブラウザで実際に確認してみます。
こんな画面が表示されていれば、OK です。



2. DSEE 6.3 のインストール

DSEE 6.3 は、こちらからダウンロードできます。 各選択肢については、以下のように選んで「View Downloads」をクリックします。
  • Step1 Select Component: Directory Server Enterprise Edition 6.x
  • Step2 Select Version: 6.3
  • Step3 Select Delivery Type: Compressed Archive(ZIP)
  • Step4 Select Platform: Solaris 10 64x86
すると、次のような画面が表示されますので、Installation Type が "Full Install" となっている箇所のリンクをクリックします。(画面で紫色になっている箇所です。)



すると、次のような画面になりますので、再度 Platform を選択し、(Solaris x64) License Agreement のボックスをチェックして、「Continue」をクリックします。



新たに表示される画面で、DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz のリンクをクリックするとダウンロードできます。



ダウンロードが終わったら、適当なディレクトリにファイルを置いて、解凍します。

# mkdir /export/DSEE
# cp DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz /export/DSEE
# cat DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz | gunzip | tar xf -

解凍後は、このような感じになっているはずです。

# ls /export/DSEE
DSEE_Directory_Editor
DSEE_Identity_Synchronization_for_Windows
DSEE_ZIP_Distribution
LICENSE.txt
Legal
README.txt
#

DSEE 6.3 をインストールします。(ここでは、Directory Editor と Identity Sync 以外の全てのコンポーネントをインストールします。)
# cd DSEE_ZIP_Distribution/
# ./dsee_deploy install -i /opt/dsee63
英語のライセンステキストが表示されるので、最後まで表示されるまでリターンキーを押し、
Do you accept the license terms ?  : に対して、「yes」と入力。
これで、/opt/dsee63 に、DSEE6.3に含まれているディレクトリサーバーなどがインストールされました。 Access Manager の配備用に、インスタンスの作成、起動およびサフィックスの作成を済ませておきます。

# cd /opt/dsee63
# ./dsadm create /export/dsins1
# ./dsadm start /export/dsins1
# ./dsconf create-suffix dc=example,dc=com
# ./dsconf import /opt/dsee63/ds6/ldif/Example.ldif dc=example,dc=com

(ここでは念のため、空のサフィックス dc=example,dc=com を作ったあとに、Example.ldif をインポートしています。)
これで、ディレクトリサーバーの準備が整いました。

3. JavaES5 U1 のインストーラを用いて AM 7.1 をインストール

次に、JavaES 5 U1 のインストーラを起動して、AM 7.1 をインストールします。
インストーラを起動する際には、ja_JP.UTF-8 ロケールで起動することをお勧めします。 なぜその方がよいかはあとの項目で説明します。
諸事情により、ja ロケールなど、UTF-8 以外のロケールで起動したい場合は、それで進めてもかまいません。(あとでワークアラウンドで対処します。)
ソフトウェアコンポーネントの選択画面では、Access Manager 7.1 の全てのコンポーネントを選択し、Directory Server Enterprise Edition 6.2 のコンポーネントのチェックは全て外します。
「次へ」をクリックすると、Web コンテナの選択画面が表示されますので、「互換性のある Web コンテナが、このシステム上にすでにインストール済み」を選択します。
さらに、依存関係の警告画面が表示されますので、ここでは「リモートマシンにインストールされている Directory Server Enterprise Edition 6.2 を使用する」を選択します。 注意:これは、あくまで、DSEE6.2 のインストールを回避するためであり、実際には、ローカルにある DSEE6.3 を使います。
これで、画面を先に進めていくと、アップグレードの必要がある共有コンポーネントが表示されます。その中に、Cacao も含まれていますが、インストール済みと必要なバージョンについて見てみると、必要なバージョンの方が古い(パッチのリビジョンが低い)ことに気づくかと思います。



JavaES 5 U1 がリリースされた時点では、JavaES 5 U1 に同梱されている Cacao のパッチのリビジョン(123896-03)が最も新しかったために、その想定のもとにインストール時には常に Cacao のパッケージを入れ替える動作になっていました。
しかしながら、Solaris 10 U6 は、JavaES 5 U1 以降にリリースされましたので、パッチのリビジョンがより新しい(123896-05) Cacao が同梱されているわけですが、JavaES 5 U1 のインストーラはその想定外のことに対処できていないわけです。結果として、古いリビジョン (123896-03) の Cacao に入れ替わってしまいます。
とりあえずここでは、画面を先に進めて、設定タイプの選択画面では、「あとで設定」を選択し、インストールを完了させます。

4. amconfig を使って、AM 7.1 を設定し、Glassfish に配備する

次に、amconfig を使って、AM 7.1 を設定し、Glassfish に配備します。 /opt/SUNWam/bin/ にある amsamplesilent を環境に合わせて編集し、 "amconfig -s amsamplesilent" と実行すればよいわけですが、ここでストップ!!!このまま実行してはいけません!
もし、そのままコマンドを実行すると、途中で以下のようなエラーが出て設定に失敗してしまいます。
:
:
Creating the agent security materials in /etc/opt/SUNWmfwk/config/security
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
No Java runtime found.
Error : Calling [genkey]
Cleaning up config in /etc/opt/SUNWmfwk/config
amconfig : Looking for registered module...
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
Cannot find property: [cacao.embedded].
:
:
先ほど説明しましたように、JavaES 5 U1 によって、Cacao が古いリビジョンに入れ替わってしまってます。そのため、cacaoadm のコマンドが動きません。 試しに、以下のコマンドを実行してみてください。

# cacaoadm status
Cannot find property: [cacao.embedded].

こんな結果が返ってくるはずです。
この問題を解決するには、もう一度、パッチ 123896-05 をインストールして、Cacao のリビジョンを Solaris 10 U6 に同梱されているリビジョンに戻してあげる必要があります。(sparc 版の場合は、123893-05 です。)

注意事項1: JavaES 5 U1 のインストーラによって Cacao のパッチのリビジョンがダウングレードしてしまったため、Cacao の最新のリビジョンのパッチを再度インストールする。

必要なパッチは、Sunsolveよりダウンロードできます。

# patchadd 123896-05
:
(中略)
:
Patch 123896-05 has been successfully installed.
See /var/sadm/patch/123896-05/log for details

Patch packages installed:
  SUNWcacaort

#


試しにさきほどと同じコマンドを実行してみます。

# cacaoadm status
default instance is DISABLED at system startup.
default instance is not running.

今度はこのようにステータス情報が正しく返ってくるはずです。
これで、Cacao の状態は正常に戻ったので、amconfig コマンドを使って、 Access Manager の設定と配備を行うことができますが、 その前に注意すべきことがあります。
amconfig コマンドを使って、Access Manager の設定を行っている過程の最後の方で、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml ファイルの中に、SUNWamsdkconfig パッケージのバージョン情報や、インストールされた日付などが書き込まれます。
amconfig 実行前のファイル:

  <parameter>
  <param-name>RevisionNumber</param-name>
  <param-value>AM_VERSION</param-value>
  </parameter>
<!--
       The InstalledProduct's Installation Date in milliseconds.
-->
  <parameter>
  <param-name>InstallDate</param-name>
  <param-value>AM_INSTDATE</param-value>
  </parameter>

amconfig 実行後のファイル:

-->
  <parameter>
  <param-name>RevisionNumber</param-name>
  <param-value>7.1,REV=06.12.15.12.35</param-value>
  </parameter>
<!--
       The InstalledProduct's Installation Date in milliseconds.
-->
  <parameter>
  <param-name>InstallDate</param-name>
  <param-value>11月 27 2008 13:36</param-value>
  </parameter>
ここで、InstallDate の日付の文字列に「月」という日本語が含まれています。これがちょっとくせものです。
JavaES 5 U1 のインストーラが、SUNWamsdkconfig を pkgadd したときのインストール日時の値が、/var/sadm/pkg/SUNWamsdkconfig/pkginfo の INSTDATE の値に書き込まれます。
INSTDATE=11月 27 2008 13:36

この日付の値は、インストーラを ja ロケールで起動していれば、EUC エンコーディングで、ja_JP.UTF-8 ロケールで起動していれば、UTF-8 エンコーディングで書き込まれます。
そして、amconfig の実行中に、この INSTDATE の値が、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml に書き込まれます。
ところで、/etc/opt/SUNWam/config/com.sun.cmm.am.xml の最初の行を見ると、
<?xml version='1.0' encoding='utf-8'?>
という風に、"このファイルは UTF-8 エンコーディングで書かれてますよ。" と宣言されています。
つまり、JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケールで起動していれば、 日付の値が UTF-8 エンコーディングで書き込まれるため、そのまま amconfig を実行したときに何も問題が起こらないわけです。
さきほど、インストーラを ja_JP.UTF-8 ロケールで起動することをお勧めします。と書いたのはこういった理由があるからです。
もし、インストーラを ja ロケールで起動していたとすると、日付の値は EUC エンコーディングになっているため、そのまま amconfig コマンドを実行すると、 /etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーは、UTF-8 で定義されているのに、中身が EUC エンコーディングになっている、という矛盾によって、次のようなエラーが発生して、amconfig は途中で失敗してしまいます。
Cannot execute command deploy: Invalid byte 1 of 1-byte UTF-8 sequence.

このエラーに対処するには、あらかじめ、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーのエンコーディングの定義を適切な値に変えておく必要があります。
例えば、次のように編集します。
<?xml version='1.0' encoding='eucJP'?>

このように編集した上で、amconfig -s amsamplesilent を実行すると、ja ロケール環境でも amconfig による設定が完了します。
:
:
Deploying Node Agent in Cacao from descriptor '/etc/opt/SUNWmfwk/xml/com.sun.mfwk.xml'
Registering Node Agent in Cacao from descriptor '/etc/opt/SUNWmfwk/xml/com.sun.mfwk.xml'
amconfig : Looking for registered module...
amconfig : Registration successful !
amconfig : Restarting cacao. Please wait...
amconfig : Restart of cacao was successful !
#

注意事項2: JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケール以外で起動した場合には、amconfig を実行する前に、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーでのエンコーディングの定義を適切な値に変えておく。

5. 配備ができたことを確認する

さて、amconfig コマンドが完了したら、glassfish を再起動して、AM 7.1 が正しく配備できたかどうかを確認してみます。
が、その前に、またまた注意事項があります!
asenv.conf(アプリケーションサーバーをインストールしたディレクトリの下の config ディレクトリに含まれているファイル) の中の次の行を変更する必要があります。
< AS_NSS="/opt/SUNWappserver/lib"
> AS_NSS="/usr/lib/mps/secv1:/opt/SUNWappserver/lib"

この変更を行わずに glassfish を再起動すると、
[#|2008-11-27T15:51:42.027+0900|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;_RequestID=dd8f3ed3-c2f2-4847-bed0-c89e2003d13a;|WEB0207: 仮想サーバー server で Web コンテキスト StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/amserver] の起動中にエラーが発生しました
LifecycleException:  java.lang.UnsatisfiedLinkError: no jss4 in java.library.path

このように、jss4 が見つかりません、というエラーが server.log に出力されます。
実際に、amserver コンソールにアクセスしても、次のようなエラーになります。



このエラーは、AS_NSS で定義された /opt/SUNWappserver/lib ディレクトリに libjss4.so が存在しないために発生します。libjss4.so は /usr/lib/mps/secv1 に存在するため、そのパスを AS_NSS の値に追加する必要があります。
そのため、上記で述べたように asenv.conf を変更する必要があるわけです。

注意事項3: asenv.conf の AS_NSS に libjss4.so が存在するパスを指定してから、glassfish を起動する。


asenv.conf を修正してから、再度 glassfish を起動すると。。。。



このように、Access Manager のログインページが表示されます。
amadmin でログインしてみると、以下のように正しくページが表示されるはずです。



これで、Access Manager 7.1 を Solaris 10 U6 上で、Glassfish に配備することができました。
もう一度注意事項を以下に記しておきます。全部で3点です。

  • 注意事項1: JavaES 5 U1 のインストーラによって Cacao のパッチのリビジョンがダウングレードしてしまうので、JavaES 5 U1 のインストールの後に、Cacao の最新のリビジョンのパッチを再度インストールする。
  • 注意事項2: JavaES 5 U1 のインストーラを ja_JP.UTF-8 ロケール以外で起動した場合には、amconfig を実行する前に、/etc/opt/SUNWam/config/com.sun.cmm.am.xml のヘッダーでのエンコーディングの定義を適切な値に変えておく。
  • 注意事項3: amconfig による設定が終わったら、asenv.conf の AS_NSS に libjss4.so が存在するパスを指定してから、glassfish を起動する。


水曜日 6 20, 2007

Instant Messaging を使ってみよう(3)


今回は、あとから会議室に参加したユーザーが、それまでの対話の内容を参照したい場合に有効な、履歴保持機能について紹介します。
まず最初に、メンバー全員が書き込み可能な会議室を用意します。
そのためには、いずれかのユーザーに会議室を作成する権限を割り当てなければなりません。
ここでは、imadmin に、IM Administrator ロールを割り当てることにします。IM Administrator ロールが割り当てられたユーザーは、IM 上でのあらゆる管理権限を行使できます。
今回の配備環境では、 Access Manager でポリシーを管理していますので、割り当て作業は AM のコンソール上で行います。
  1. AM の管理コンソール(amconsole)に amadmin でログインする。
  2. 表示から「ロール」を選択する。
  3. 左の区画にロールの一覧が表示されるので、そこから IM Administrator の三角印をクリックする。
  4. 右の区画で「追加」をクリック
  5. ユーザーID: フィールドに「imadmin」と入力し、「次へ」をクリック。

  6. このように、imadmin がリストされるので、それを選択して、「終了」をクリック。
これで、imadmin に、IM Administrator ロールが割り当てられました。
imadmin で IM にログインしてみると、次のように「ツール」メニューに「会議室を管理」という項目が表示されるはずです。imtest1 でログインした場合には、その項目は表示されませんので、比較してみてください。

それでは、以下のようにしてメンバー全員が書き込み可能な会議室を作成しましょう。
  1. 「ツール」→「会議室を管理」を選択。
  2. ポップアップウインドウで「新規会議室」をクリック。
  3. ID フィールドには、覚えやすい英数字を入力します。この ID はあとで会議室を検索する場合に使われるものです。例えば、room1 とします。
  4. 名前フィールドに会議室の名前を入力します。こちらは、日本語を使ってもかまいません。例えば、会議室1 とします。
  5. デフォルトアクセス権を「書き込み」に設定して、「了解」をクリックします。
これで、特別に権限を設定されたユーザー以外は、デフォルトでこの会議室に書き込みができます。
imadmin の方は、会議室を作成した時点で、「会議室」タブに自動的に「会議室1」がリストされてます。
imtest1 の方は、デフォルトでは、何も会議室が登録されていないので、次の手順を行います。
  1. IM にログインしたら、会議室タブをクリックして、「ファイル」→「会議室を追加」を選択
  2. ID フィールドに「room1」と入力し、検索をクリック。
  3. 「了解」をクリック。
これで、imtest1 側でも、会議室1がリストに表示されたはずです。
試しに、imadmin と imtest1 それぞれ、この会議室に入室して、書き込んでみましょう。

こんな風に双方の書き込んだ内容が表示されます。

さて、ここで、この会議室に imtest2 が遅れて参加する場合を考えます。 デフォルトでは、imtest2 が会議室に入室した時点で、それ以前の imtest1 と imadmin の対話内容は表示されません。

ここで、履歴機能をオンにしてみます。
方法は、いたって簡単です。iim.conf ファイルに次の行を追加し、再起動します。
iim_server.conference.history.maxstanzas = 15
iim_server.conference.history.maxstanzas.default = 10

IM は、iim_server.conference.history.maxstanzas.default で定義された件数分、メッセージを履歴として保持します。また、この値は、1 から iim_server.conference.history.maxstanzas の値の間で定義します。
デフォルトでは、iim_server.conference.history.maxstanzas の値は 10 なので、それ以上にしたい場合は、iim_server.conference.history.maxstanzas も定義します。 上の例だと、履歴は最新10件分保持されることになります。

したがって、最初に imtest1、次に imadmin が会議室1に入室して、対話をしていたところへ、あとから、imtest2 が入室した場合、
imtest1 では以下のように表示されているとき、


imtest2 のウインドウでは、自分自身の書き込み内容とともに、過去10件のメッセージも履歴として表示されています。


これで、あとから入室したり、あるいはいったん退室して入り直したときでも、直近のメッセージを見ることができます。
注意事項:
  • メッセージの横に表示されているタイムスタンプは、各ユーザーが会議室に入室した時点の時刻をベースにリセットされて表示されます。例えば、imtest1 が 6月20日の午後2時から10件書き込みして退室し、imtest2 が、同日の午後5時に入室した場合、imtest1 の過去の10件の書き込みのタイムスタンプは、午後2時ではなく、午後5時として表示されます。(バグID: 6362452)
  • サーバーを再起動した時点で、履歴はすべてクリアされます。(仕様)

火曜日 6 19, 2007

Instant Messaging を使ってみよう(2)


今回はカレンダーリマインダー機能を通して、IM と CS がうまく連動していることを確認してみます。
まずは、カレンダーリマインダー機能が使えるように、CS の設定ファイルをカスタマイズします。
# vi /opt/sun/calendar/config/ics.conf
caldb.serveralarms = "1"  ←"no" を 1 に変更
caldb.serveralarms.url = "enp:///ics/customalarm" ← コメントはずす
caldb.serveralarms.contenttype = "text/calendar"←コメントはずして、"text/xml" を "text/calendar" に変更
変更が終わったら、CS を再起動します。
# /opt/sun/calendar/sbin/stop-cal
# /opt/sun/calendar/sbin/start-cal
これで、準備完了です。次に以下の操作を行います。
  1. imtest1 で、Calendar Express にログインします。(http://host:8103)
  2. オプション->設定へと移動し、タイムゾーンを「アジア/東京」に変更します。
  3. 「表示」タブをクリックし、「新しい予定」をクリックします。
  4. タイトル、日付、時刻、開催場所、説明を入力します。
  5. アラームタブをクリックして、アラーム時刻を設定します。
  6. 例えば、予定の時刻が 6月14日 13:30 だとして、その3分前にアラームを送るように設定します。
  7. 「了解」をクリックすると、予定が作成されます。
  8. imtest1 で、IM にログインし、アラーム時刻を待ちます。
  9. 次のようなポップアップが表示されれば OK です。

ちなみに、このポップアップが表示されるのと同時に、アラームで設定されているメールアドレスにも同じ内容のものが送信されています。
Messenger Express に imtest1 でログインして、メールが受信されていることを確認してみてください。
これで、CS ともうまく連動して IM が動いていることを確認できました。

金曜日 6 15, 2007

Instant Messaging を使ってみよう(1)


前回までにセットアップした環境で、IM を使って、MS, CS とのコラボが確立できてる ことを確かめてみます。
そのために、ここでは、IM のオフラインアラート機能と、カレンダーリマインダー機能を使ってみます。
まずはじめに、username@japan.sun.com でメールが送れるように ldapmodify でエントリをカスタマイズしておきます。
changetype: modify
add : mailAlternateAddress
mailAlternateAddress: imtest1@japan.sun.com
mailAlternateAddress: imtest1

dn: uid=imtest1,ou=people,o=tgc,dc=japan,dc=sun,dc=com
changetype: modify
replace : mail
mail: imtest1@dione.japan.sun.com
このあと、以下のコマンドを実行して、MS を再起動します。
/opt/sun/messaging/sbin/imsimta cnbuild
/opt/sun/messaging/sbin/imsimta restart
/opt/sun/messaging/sbin/stop-msg
/opt/sun/messaging/sbin/start-msg
次に、/opt/sun/im/config/iim.conf ファイルに、次の行を追加します。
iim.mail.charset="iso-2022-jp"
これは、メールを iso-2022-jp エンコーディングで送信することを意味します。ここには、他のエンコーディングを指定してもかまいません。(何も指定しないと、US-ASCii で送信するため、日本語が文字化けしてしまうので注意してください。)
iim.conf を編集したら、imadmin refresh で、各コンポーネントを再起動します。
再起動が終わったら、imtest1 で IM にログインします。
  1. 「ファイル」メニューから「連絡先を追加」を選択します。
  2. 名前:フィールドで、あいえむ\* と入力し、「連絡先を検索」ボタンをクリックします。

  3. 別のポップアップがあがってくるので、自分以外のユーザー2人を選択し、「了解」をクリックします。
  4. 「連絡先を追加」ウインドウで「了解」をクリックします。

  5. 今追加したユーザーの横には?マークが出てると思います。これは、それぞれのユーザーに対して、連絡先に追加してもいいかどうか承認待ちの状態にあることを意味します。
  6. imtest2 で、IM にログインします。

  7. こんなウインドウが表示されるので、「了解」を選びます。imtest1 側にも似たようなウインドウが表示されるので、そこでも「了解」を選びます。これを imadmin に対しても同様に行います。
  8. 次に、imtest1 のウインドウで「ツール」メニューから「設定」を選びます。
  9. 「アラート」タブの「オフラインアラート電子メールアドレスへ転送」フィールドに、転送用のメールアドレスを入力します。(例 imtest1@japan.sun.com)
  10. あとで、CS とのコラボテストを行うために、カレンダリマインダ表示のチェックボックスを ON にして、「了解」をクリックします。
  11. imtest1 のウインドウを閉じます。(「ファイル」->「終了」)
  12. これで、imtest1 はオフラインの状態になりました。imtest2 から見ると、こんな風に、imtest1 がオフラインになってることがわかります。(アイコンが薄い灰色)

  13. imtest1 を選んで、「ツール」->「アラート」を選択します。
  14. アラート作成ウインドウが表示されるので、件名と本文を入力して、送信します。

  15. オフラインアラートがメールで届いているかを確認するために、Messenger Express に imtest1 でログインします。(http://host:8100 少し時間をおいてから、確認した方がいいかもしれません。)

  16. こんな風に、オフラインアラートがメールで送られてきます。
カレンダーリマインダー機能については、次回!

木曜日 6 14, 2007

Instant Messaging のセットアップ(2)


(前回からの続きです)

6. IM の設定

次に、/opt/sun/im/configure コマンドにより、IM を設定します。
  • ユーザー管理オプションでは、両オプションともに、AM を使用する を選択。
  • 実行時ユーザー ID とグループ ID は、どちらも root にする。
  • DS オプションで、ベース DN は、dc=japan,dc=sun,dc=com にする。
  • HTTP ゲートウェイ設定は、no にする。
  • カレンダ統合は有効にする。
次に、AM 上でいくつか設定を行います。

7. AM の設定

  1. まず、AM の管理コンソール http://host:port/amconsole に amadmin でログインします。
  2. 表示メニューから「組織」を選択し、IM ユーザー用の組織(この例では、tgc)のリンクをクリックします。
  3. 右の区画にドメイン名が記載されてることを確認してください。(この例では、japan.sun.com)
  4. 表示メニューから「サービス」を選択します。
  5. 「追加」をクリックします。
  6. 右の区画に追加可能なサービス一覧が表示されます。下の方に以下の2つのサービスが表示されてるはずなので、両方ともチェックして、「了解」をクリックします。
    • Instant Messaging Service
    • Presence Service
  7. リストから、「コア」のリンクをクリックします。
  8. 右の区画で、組織認証設定:に何も設定されてなかったら、リストから有効の値を選択します。(デフォルトなら、ldapService が選択できるはずです。)
  9. 「保存」をクリックします。
  10. 表示メニューから「ユーザー」を選択します。
  11. リストから、imadmin を選択します。
  12. フルネームが firstname lastname の順番になってるので、これを入れ替えます。
  13. 右の区画で「サービス」を選択し、「追加」をクリックします。
  14. リストされてるサービスを全部選択して、「了解」をクリックします。
  15. 同じ作業を、imtest1, imtest2 に対しても繰り返します。
これで、設定は終わりました。 早速、IM にログインしてみましょう。
IM にログインするには、まず http://host:port/im/ja にアクセスし、Java Web Start が利用可能な場合は「起動」ボタンをクリックします。もしくは、ページ上部にある「Java プラグインを起動する」をクリックします。
次のようなウインドウが表示されますので、ユーザー名に、imtest1 を入力し、パスワードを入れて、ログインしてみましょう。


こんな画面が表示されたら、OK です。(\^\^)



次回は、MS と CS とのコラボという観点から、オフラインアラート機能と、カレンダーリマインダー機能について触れてみます。

水曜日 6 13, 2007

Instant Messaging のセットアップ(1)


リリースから大分経ちましたが、今回は、Sun Java Communication s Suite 5に入っている、Instant Messaging を他の Communication 製品(Messaging Server & Calendar Server) とコラボさせた形で使用するために、必要な製品をインストール&セットアップする流れについて書こうと思います。
今回は以下のように配備することとします。
  • プラットフォーム:Red Hat Enterprise Linux AS release 4(Update1)
  • インストールする製品
    • Instant Messaging(以下、IM)
    • Messaging Server(以下、MS)
    • Calendar Server(以下、CS)
    • Delegated Admin(以下、DA)
    • Directory Server(以下、DS)
    • Web Server(以下、WS)
    • Access Manager(以下、AM)
  • IM および AM は、WS 上に配備する
  • 特に明記してない限り、ポート番号はデフォルトのものを使用
  • root DN: dc=japan,dc=sun,dc=com
  • IM/MS/CS を使うユーザーが属する組織 DN: o=tgc,dc=japan,dc=sun,dc=com
まず、はじめに、ここから Linux platform 用のイメージをダウンロードし、zip ファイルを展開後、上記の製品を「今すぐ設定」オプションを使ってインストールします。 (ただし、IM, MS, CS, DA については、インストール時にセットアップできませんので、これらはあとで説明する手順に沿って、別途セットアップします。) インストールが完了したら、DS と WS を起動して、残りの製品のセットアップを始めます。

1. Communication Suites 製品のセットアップの流れ

大まかな流れを書きますと、
  1. Directory Server Prepartion Tool の実行
  2. MS のセットアップ
  3. CS のセットアップ
  4. config-commda と commadmin を用いて組織を設定し、ユーザーを作成する
  5. IM のセットアップ
  6. AM のセットアップ
とこんな感じになります。

2. Directory Server Prepartion Tool を実行する

まずはじめに、comm_dssetup.pl スクリプトを実行します。 このスクリプトは、インストールされている DS が Communication Suite とともに動作するようにスキーマを拡張したり、必要なインデックスを設定したりします。
このスクリプトは、/opt/sun/comms/dssetup/sbin にあります。
# cd /opt/sun/comms/dssetup/sbin
# perl comm_dssetup.pl
:
(中略)
:
There are 3 possible schema types:
  1   - schema 1 for systems with iMS 5.x data
  1.5 - schema 2 compatibility for systems with iMS 5.x data
        that has been converted with commdirmig
  2   - schema 2 native for systems using Access Manager

Please enter the Schema Type (1, 1.5, 2) [2]: 2
:
基本的に、デフォルトで提示されてるオプションを受け入れていけば、問題なくセットアップが終わります。

3. MS のセットアップ

次に、MS を使えるようにセットアップします。
cd /opt/sun/messaging/sbin
./configure -nodisplay
:
(中略)
   UNIX グループを入力 [mail]: mailgrp
:
(中略)
:
   ポストマスターのメールアドレスを入力 [] admin@japan.sun.com
:
(中略)
:
組織 DN を入力 [o=japan.sun.com,dc=japan,dc=sun,dc=com] o=tgc,dc=japan,dc=sun,dc=com
:
ポートがコンフリクトするという旨の warning が出ますが、
これは、MS のデフォルトポートが 80 になっていて、
先にインストールした WS のポートと重複してるためです。
これは、あとで解決することにして、まずは configure による設定を完了させます。
完了したら、さきほどのポート番号のコンフリクトの問題を解消します。 ここでは、MS のポートを 8100 に変更します。
# ./configutil -o service.http.port -v 8100
OK SET
次に、dcroot を dc=japan,dc=sun,dc=com にセットします。
# ./configutil -o service.dcroot -v dc=japan,dc=sun,dc=com
OK SET
# ./configutil -o local.webmail.sso.enable -v 1
# ./configutil -o service.http.ipsecurity -v no
sendmail も止めます。
/etc/init.d/sendmail stop
ulimit を 20000 に設定しておきます。(file descriptor 関連のエラー対策)
# ulimit -n 20000
最後に、DOMAIN_UPLEVEL を 3 にして、ビルドします。
# echo "DOMAIN_UPLEVEL=3" >> /opt/sun/messaging/config/option.dat
# ./imsimta cnbuild
# ./imsimta restart
これで、MS の設定は完了です。サーバーを起動します。
# ./start-msg
エラーがなく、起動が完了したら、http://host:8100 にアクセスして、admin アカウントでログインしてみてください。
次のような画面が表示されれば、OK です。

4. CS のセットアップ

次に、CS のセットアップを行います。
# cd /opt/sun/calendar/sbin
# ./csconfigurator.sh -nodisplay
:
(中略)
:
   カレンダ管理者の電子メールアドレス [root@japan.sun.com]: admin@japan.sun.com
:
(中略)
:
ランタイム設定

   サービスポート [80] 8103
:
セットアップが終わったら、ics.conf 内でいくつか手で修正すべき箇所があるので、それを行います。このファイルは、/etc/opt/sun/calendar/config/ にあります。
修正すべき箇所

service.http.ui.enable = "y"
service.dcroot = "dc=japan,dc=sun,dc=com"
修正が終わったら、サーバーを起動します。
# ./start-cal
確認のため、http://host:8103 に admin アカウントでログインしてみてください。 次のような画面が表示されれば、OK です。

5. config-commda と commadmin を用いて設定する

次に、config-commda と commadmin を用いて IM/CS/MS を使うユーザーが属する組織を設定し、commadmin を用いてユーザーを作成します。
# cd /opt/sun/comms/commcli/sbin
# ./config-commda -nodisplay
:
Access Manager のホスト名とポート番号を入力してください

   ホスト名 [dione.japan.sun.com] {"<" 戻る, "!" 終了}:
   ポート [8080] {"<" 戻る, "!" 終了}: 80
:
WEB、WEB7、APP7 または APP8 を入力し、web コンテナを指定します (WEB、WEB7、APP7 または APP8)  [WEB]
   {"<" 戻る, "!" 終了}? WEB7
:
組織 DN を入力 [o=japan.sun.com,dc=japan,dc=sun,dc=com] {"<" 戻る, "!" 終了} o=tgc,dc=japan,dc=sun,dc=com
:
設定が終わったら、WS を再起動します。
次に、commadmin コマンドを使って、組織 o=tgc に属するユーザーが、MS と CS にログインできるようにします。
# cd /opt/sun/comms/commcli/bin
# ./commadmin domain modify -D admin -w admin's password -n japan.sun.com -p 80 -d japan.sun.com -S mail,cal -H hostname
そして、次のコマンドで o=tgc 以下に、テスト用のユーザーを作成します。 ここでは、imtest1, imtest2, imadmin と 3 つのユーザーを作成しておきます。
#  ./commadmin user create -D admin -w admin's password -p 80 -d japan.sun.com -F firstname -L lastname -l imtest1 -W imtest1's password -S mail,cal -k legacy -A preferredlanguage:ja -A preferredlocale:ja

(imtest2, imadmin も同じようにして作成する)

これで、下準備が終わりました。ようやく本題の IM の設定にとりかかれます。(ふーっ。) 次回は、IM の設定と、その後に行う AM の設定について説明し、さきほど作ったユーザーで、IM にログインできるところまで書きたいと思います。

金曜日 6 08, 2007

JavaES 5 からローカライズパッケージの構成が変わりました

JavaES 5 からローカライズパッケージは、従来のような日本語パッケージ、ドイツ語パッケージ・・・といった言語単位ではなく、ローカライズ言語一括で一つのパッケージとして提供されるようになりました。
そのため、インストーラでインストールする際に、従来のように、日本語のみを選んでインストールすることはできません。
英語のみをインストールするか、英語+ローカライズ言語すべてをインストールするかの 二者択一となります。

もし、何らかの事情で、英語と日本語以外の他の言語のファイルはじゃまなので削除したい、という場合には、いったんローカライズ言語を一括してインストールしたあとで、 日本語以外のローカライズ言語のファイルを除去する必要があります。
ここでは、一例として、Solaris platform 上で、Access Manager を対象にして 他の言語ファイルを除去する手順を説明します。

JavaES 5 Access Manager で、日本語以外のローカライズ言語のファイルを除去する方法

前提条件:

  • Access Manager は、JavaES 5 インストーラの「今すぐ設定」オプションを使って デフォルトのディレクトリ(/opt/SUNWam) にインストールされている。
  • 言語パッケージもインストールされている。
  • Access Manager は Web Server 7 に配備されている
  • Web Server 7 も、JavaES 5 インストーラでインストール済み(ディレクトリやポートなどはデフォルト設定)
  • 除去する際に英語版メッセージは残す

手順:

  1. /opt/SUNWam に移動
  2. 以下のようにして日本語以外のファイル、ディレクトリを削除する
    2-a 環境変数をセットする(/bin/sh を使ってるものとする)
    DELLANG="de es fr ko zh zh_CN zh_TW zh_HK it sv"
    export DELLANG
    
    2-b 不要な mobile_auth_jsps_\*.jar の除去
    # # for i in $DELLANG; do rm -f mobile_auth_jsps_$i.jar; done
    
    2-c /opt/SUNWam/locale 以下での除去作業
    # cd locale
    # for i in $DELLANG; do rm -f \*_$i.properties; done
    # rm -rf zh zh_\* ko ko.UTF-8 ko_\* fr fr.UTF-8 fr_FR\* es.UTF-8 es es_ES\* de de.UTF-8 de_DE\*
    
    2-d /opt/SUNWam/web-src 以下での除去作業
    # cd /opt/SUNWam/web-src
    # for i in $DELLANG; do rm -rf \*/com_sun_web_ui/html/$i; rm -rf \*/html/$i; rm -f \*/WEB-INF/lib/cc_$i.jar; rm -rf services/config/auth/default_$i; done
    
    2-e /opt/SUNWam/amclient/locale 以下での除去作業
    # for i in $DELLANG; do rm -f \*_$i.properties; done
    
    2-f /opt/SUNWam/amauthdistui/locale 以下での除去作業
    # for i in $DELLANG; do rm -f \*_$i.properties; done
    
    2-g /opt/SUNWam/public_html/online_help 以下での除去作業
    # for i in $DELLANG; do rm -rf docs_$i\*; done
    
    2-h /opt/SUNWam/samples/authentication/spi/jcdi 以下での除去作業
    # for i in $DELLANG; do rm -f \*_$i.xml \*_$i.properties; done
    
    2-i /opt/SUNWam/samples/authentication/spi/providers 以下での除去作業
    # for i in $DELLANG; do rm -f \*_$i.xml; done
    
    2-j /opt/SUNWam/Legal 以下での除去作業
    # for i in $DELLANG; do rm -f \*_$i.sxw \*_$i.txt; done
    # rm -f \*_zh\*.sxw \*_cn.txt \*_tw.txt
    
    以上で、除去完了です。
  3. 再配備を行う
    3-a /opt/SUNWam/bin に移動
    3-b amsamplesilent の作成
    # cp amsamplesilent amsamplesilent.jaonly
    # chmod 644 amsamplesilent.jaonly
    
    3-c amsamplesilent.jaonly を配備環境にあわせて編集
    書き換えたり、コメントをはずしたりすることが必要な箇所のみ記載。
    
    DEPLOY_LEVEL=21
    SERVER_NAME=eomer.japan.sun.com  
    SERVER_HOST=$SERVER_NAME
    SERVER_HOST=80
    ADMIN_PORT=8989
    DS_HOST=eomer.japan.sun.com
    DS_DIRMGRPASSWD=adminadmin
    ROOT_SUFFIX="dc=sun,dc=com"
    ADMINPASSWD=adminadmin
    AMLDAPUSERPASSWD=admin123
    WEB_CONTAINER=WS
    
    AM_REALM=disabled (realm mode でインストールしていれば true そうじゃなければ false)
    
    3-d amconfig コマンドを用いて再配備する
    # amconfig -s amsamplesilent.jaonly
    
  4. 4 Web コンテナを再起動する
    # /var/opt/SUNWwbsvr7/https-/bin/stopserv
    # /var/opt/SUNWwbsvr7/https-/bin/startserv
    

水曜日 2 21, 2007

JES を Windows に入れてみた

仕事柄、JES をインストールすることは日常茶飯事なのですが、
ほとんどが、Solaris や Linux が対象プラットフォームでして、
めったに Windows にインストールすることはありません。
(ちなみに、HP-UX へのインストールはしたことないです。マシンがないので\^\^;)

しかし、最近、ある用件で、幾度となく Windows 上に JES をインストールする
機会があり、これまで経験してきた Solaris/Linux 上へのインストールと比べると
便利な面、不便な面両方あるなぁと改めて気づきました。

○便利な面。
最小労力ですべて事が進む。

インストール時に自動設定を選んだ場合、製品選択や、管理IDとパスワードの入力を
除けば、何の値も入力することなく、インストーラーが製品のインストールから、
設定まですべてやってくれます。すごい楽チンです(\^\^)

●不便な面
融通が利かない(苦笑)

たとえば、Access Manager をインストールするのに、
Directory Server は他のマシン上のものを使うからインストールする必要がない場合、
これが、Solaris/Linux の JES インストーラーなら、
製品選択で、Access Manager を選び、Directory Server は選ばずとも、
「今すぐ設定」を選ぶことができ、外部の Directory Server を指定することで、
インストール&設定を済ませることができます。
ところが、Windows 版の場合、自動設定でインストールしたいのなら、
Access Manager を選択した時点で、Directory Server の選択も強要されてしまい、
それがいやなら、手動設定の道をたどるしかないはめになります。。。

別のシナリオとしては、Application Server や Directory Server は
自動設定でインストールしたいが、
Access Manager は、都合により手動設定でインストールしたい場合があるとします。
Solaris/Linux 版なら、最初に Application Server と Directory Server を
「今すぐ設定」でインストールし、もう一度インストーラーを起動して、
今度は Access Manager を「あとで設定」でインストールすることができます。
ところが、Windows 版では、一度「自動設定」でインストールしちゃうと、
次にインストーラーを起動したあときも「自動設定」が強要されてしまいます。
もし、いずれかの製品を手動設定でインストールしたいのなら、
最初からすべての製品を手動設定でインストールしなければならないのです。
逆に、最初に「手動設定」である製品をインストールすると、
次からも「手動設定」でインストールすることになります。。。

Windows 版のインストーラーは、なるべくユーザーに手間隙かけさせない、
入力・選択事項を極力少なくするという設計方針になってるんだとは思いますが、
ここまで徹底されちゃうと、もう少し融通きかせてよと言いたくなっちゃいますね。
JES に大きくかかわってる者として、あまり身内のことをとやかく言うのもなんですが(苦笑)

もうまもなくリリースされる JES release 5 では変わることはないですが、
将来のリリースに向けて、もう少し柔軟性に富んだ動作をしてくれるように、
改善要求でも出しておこうかな・・・・

土曜日 2 04, 2006

Directory Server を共有する形で、Access Manager を 2台のマシンに配備する方法

Access Manager(以下 AM) を2台(もしくはそれ以上の複数)のマシンに配備して、 双方を1つのマシンに配備した Directory Server(以下 DS) とつないで使用する… つまり、DS を共有する形で、AM を複数のマシンに配備したいケースってありますよね。

最近、私もお客さまからのサポートコールで、実際にこのケースにおけるトラブルと 格闘しておりまして、最終的には開発チームからのヘルプなどにより、 無事に配備することができました。 結局は、設定不備が原因であり、いくつかのポイントに注意して設定を行えば 問題なく行えるということがわかりました。そこで、そのときに苦労した経験をもとに、 今後はスムーズに設定、配備が行えるように、実際に行う操作などを細かく書きながら、具体的な手順書を記しておこうと思います。

ここでは、次のような簡単な配備シナリオを想定して、以下話をすすめていきます。

  • AM の配備コンテナには Web Server(WS) を使用する。
  • host1.japan.sun.com: AM と DS と WSをインストール
  • host2.japan.sun.com: AM と WS をインストール。DS は、host1 に設定されたものを利用するので、インストールしない。
  • Messaging Server などの comms product と共存させることを想定して、両方の AM とも、legacy mode でインストールする。
1. 1台目のマシンに コンポーネントをインストールする
  1. JES インストーラを使って、AM, WS, DS を選択して、「すぐに設定(Config now)」モードで、インストールします。
  2. インストールが終わったら、すべてのサーバー(DS, WS, AM)を再起動します。
  3. 念のため、AM console に amadmin でアクセスできることを確認します。
    • http://host1.japan.sun.com/amconsole
2. host2 の情報を host1 の AM console に設定する。
  1. amadmin ユーザーで、AM console にログインします。
    • http://host1.japan.sun.com/amconsole
  2. ログインすると、最上位の組織の一般プロパティーが右側に表示されているはずです。
  3. 「組織のエイリアス」のリストの下のテキストフィールドに2台目のマシンのホスト名を入力して、「追加」をクリック。
    • host2.japan.sun.com
  4. host2.japan.sun.com が組織のエイリアスリストに追加されます。「保存」をクリックして変更内容を確定します。
  5. 次に、「サービス設定」タブをクリックします。
  6. サービス名の一覧が表示されますので、そこから「プラットフォーム」の右側にある三角印をクリックします。
  7. 右側の区画にプラットフォーム設定が表示されます。
  8. サーバーリスト:というリストがありますので、その下のテキストフィールドに次のように入力し、「追加」をクリック。
    • http://host2.japan.sun.com:80|02
  9. この時点で、リストには、2つのエントリがあるはずです。(順不同)
    • http://host2.japan.sun.com:80|02
    • http://host1.japan.sun.com:80|01
  10. 「保存」をクリックして、プラットフォームに関する変更内容を確定します。
これで、1台目のマシンに関する設定は終わりました。もう一度すべてのサーバー(DS, WS, AM)を再起動させます。 次に、2台目のマシンの設定を行います。

3. 2台目のマシンに コンポーネントをインストールする

  1. JES インストーラを使って、WS を選択して、「すぐに設定(Config now)」モードで、インストールします。
  2. WS を起動します。
  3. もう一度、JES インストーラを使って、AM を選択し、今度は「あとで設定(Config later)」モードでインストールします。
これで、2台目のマシンでは、WS のインストールおよび設定は完了しており、AM については、インストールのみが完了し、これから手で設定を行うことになります。

4. 2台目のマシンの AM の設定を行う

  1. AM がインストールされたディレクトリに移動し、さらにその下の bin ディレクトリに移動します。
    • sparc の場合: /opt/SUNWam/bin
    • linux の場合: /opt/sun/identity/bin
    • そこに、amsamplesilent というファイルがあります。まず、このファイルを環境にあわせて書き換える必要があります。

4.1 amsamplesilent のカスタマイズ

amsamplesilent ファイルには、Access Manager をどこに配備するか、どのマシンの Directory Server と共存させるか、など、設定に必要な情報が色々と書かれています。ここでは、AM を WS に配備することを想定して、ファイルのどこを書き換えればいいかを説明します。 (逆にいえば、ここで触れてないものは、インストール時にデフォルトを選択している限り、現存の値をそのまま使って大丈夫ということです。)

ファイルを上から見ていって、まずは以下のブロックのところを修正していきます。修正する前はこんな風になってるはずです。先頭の # はコメントを意味するので、# をはずします。

#SERVER_NAME=example  -> AM を設定するホスト名を書く。
#SERVER_HOST=$SERVER_NAME.sun.com -> 上記ホスト名をFQDN 形式で書く
#SERVER_PORT=58080 -> AM の配備コンテナのポート番号
#ADMIN_PORT=4849   -> AM の配備コンテナの管理ポート番号
#DS_HOST=example.sun.com -> DS のホスト名(FQDN形式)
#DS_DIRMGRPASSWD=11111111 -> DS の admin パスワード
#ROOT_SUFFIX="dc=sun,dc=com" -> DS のルートサフィックス
#ADMINPASSWD=11111111 -> AM の amadmin のパスワード
#AMLDAPUSERPASSWD=00000000 -> amldapuser のパスワード
#COOKIE_DOMAIN=.sun.com -> クッキードメイン。
(1台目のマシンに、AM をインストールした際に、JES installer の、AM設定画面(4/6) にて設定した値とあわせておけば間違いないでしょう。)
#AM_ENC_PWD="" -> 1台目のマシンの AMConfig.properties の am.encryption.pwd の値と同じにする。
#NEW_OWNER=root -> これは、そのままでよい。
#NEW_GROUP=other -> Solaris ならそのまま、Linux なら、root
#PAM_SERVICE_NAME=other -> Solaris ならそのまま、Linux なら、password とする。
#WEB_CONTAINER=AS8 -> 配備コンテナを指定。WS なので、WS6 を指定。

たとえばこんな感じになります。

SERVER_NAME=host2
SERVER_HOST=host2.japan.sun.com
SERVER_PORT=80
ADMIN_PORT=8888
DS_HOST=host1.japan.sun.com
DS_DIRMGRPASSWD=adminadmin
ROOT_SUFFIX="dc=japan,dc=sun,dc=com"
ADMINPASSWD=adminadmin
AMLDAPUSERPASSWD=admin123
COOKIE_DOMAIN=.sun.com
AM_ENC_PWD="+DumXHpKF72p4WHSmg+FhqpKNGi4dAYv"
NEW_OWNER=root
NEW_GROUP=other
PAM_SERVICE_NAME=other
WEB_CONTAINER=WS6

参考までに、App Server に配備するのなら、こんな風になります。(ポート番号関連と、WEB_CONTAINER の値が変わる)

SERVER_NAME=host2
SERVER_HOST=host2.japan.sun.com
SERVER_PORT=8080
ADMIN_PORT=4849
DS_HOST=host1.japan.sun.com
DS_DIRMGRPASSWD=adminadmin
ROOT_SUFFIX="dc=japan,dc=sun,dc=com"
ADMINPASSWD=adminadmin
AMLDAPUSERPASSWD=admin123
COOKIE_DOMAIN=.sun.com
AM_ENC_PWD="+DumXHpKF72p4WHSmg+FhqpKNGi4dAYv"
NEW_OWNER=root
NEW_GROUP=other
PAM_SERVICE_NAME=other
WEB_CONTAINER=AS8

さらに、ファイルを見ていくと、以下の行が目にはいるはずです。

DIRECTORY_MODE=1

"1"は、新しくディレクトリを作成して、AM を設定するときの値です。今回は、すでに host1 に存在するディレクトリデータを共有するわけですから、この値を書き換える必要があります。正しい値は "4" です。

DIRECTORY_MODE=4

さらにファイルを下に見ていくと、以下の行が目にはいるはずです。

AM_REALM=enabled

これは、AM をレルムモードで設定することを意味しています。ここでは、MS などの comms product との互換を考えて、レガシーモードでの設定を想定してますので、この値を "disabled" にします。

AM_REALM=disabled

さらにファイルを下に見ていくと、以下の行が目にはいるはずです。

NEW_INSTANCE=false

注意!: この値は、同一のマシンに、2つ目の(もしくはそれ以降の)AM を設定する場合に "true" とする必要があります。ここでは、host2 には、1つしか AM を設定しませんので、false のままでOkです。(デフォルトが false なので、書き換える必要なし)

最後に、以下のブロックが WS 関連になります。もし、Linux を使用の場合は、WS61_HOME の値のみ /opt/sun/webserver にする必要があります(デフォルトディレクトリにインストールした場合)。その他の値はそのままでOKです。 Solaris を使用の場合は、このブロックは変更の必要はありません。

WS61_INSTANCE=https-$SERVER_HOST
WS61_HOME=/opt/SUNWwbsvr
WS61_PROTOCOL=$SERVER_PROTOCOL
WS61_HOST=$SERVER_HOST
WS61_PORT=$SERVER_PORT
WS61_ADMINPORT=$ADMIN_PORT
WS61_ADMIN="admin"

これで、amsamplesilent を今回の配備シナリオ用に書き換えることができましたので、実際に設定を行います。

4.2 スクリプトを使って、AM を設定する。

amsamplesilent ファイルと同じディレクトリに、amconfig コマンドがあります。引数に、さきほどカスタマイズした amsamplesilent ファイルを指定し(念のため絶対パスで指定して下さい)、設定を実行します。

# ./amconfig -s /opt/SUNWam/bin/amsamplesilent
設定が終わったら、WS と AM サーバーを再起動します。これで、すべて完了しました。
  • http://host1.japan.sun.com/amconsole
  • http://host2.japan.sun.com/amconsole
と2台のマシンの AM にそれぞれログインできるようになったはずです。
…できましたか? :-)
About

hanaki

Search

Archives
« 4月 2014
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今日