このセクションでは、SGD データストア、ユーザーアクティビティーの監視方法、およびロギングの構成方法について説明します。
このセクションの内容は、次のとおりです。
アレイ内の SGD サーバーは情報を共有します。各 SGD サーバーが知っている内容は、次のとおりです。
設定済みのアプリケーションと、それらのアプリケーションの実行元となるアプリケーションサーバー
アプリケーションにアクセス可能なユーザー
SGD サーバーにログインしたユーザー
ユーザーが実行しているアプリケーション
情報のコレクションはデータストアと呼ばれます。
ユーザー、アプリケーション、アプリケーションサーバー、および Webtop に関する情報はディスク上のローカルリポジトリ内に格納されます。ユーザーセッションとアプリケーションセッションに関する情報は、メモリー内に格納されます。
データストアは、コマンド行やログファイルで表示および使用されるネームスペースに編成されます。一般的な構造は、.../namespace/name-within-namespace
です。...
はデータストアのルートを表します。ネームスペースは DNS など、情報のソースを示します。ネームスペースのあとに、そのネームスペースに適した任意の命名規則に従って名前が記述されます。名前はファイルシステムのパスと同様に記述されます (スラッシュで区切られたトップダウン形式)。
次に、一般的に使用されるネームスペースをいくつか示します。
ネームスペース | 説明 | 例 |
---|---|---|
ローカル | ローカルリポジトリ内の SGD オブジェクト |
|
LDAP | LDAP ディレクトリにあるオブジェクト |
|
DNS | ネットワークに接続しているマシン |
|
このセクションでは、SGD でのユーザーセッションとアプリケーションセッションの違いについて説明します。Administration Console とコマンド行を使ってユーザーセッションとアプリケーションセッションの監視や制御を行う方法についても説明します。
このセクションの内容は、次のとおりです。
ユーザーセッションは、ユーザーが SGD にログインした時点で始まり、ユーザーが SGD からログアウトした時点で終わります。ユーザーセッションは、ユーザーがログインした SGD サーバーによってホストされます。ユーザーが入力したユーザー名とパスワードが、ユーザーのタイプを決定します。ユーザー認証の詳細については、2章ユーザー認証 を参照してください。
すでにユーザーセッションが開かれている場合にユーザーがログインすると、ユーザーセッションは新しい SGD サーバーに転送され、古いセッションは終了します。これは、セッションの移動またはセッションの乗っ取りと呼ばれることがあります。
ユーザーセッションには、標準セッションまたはセキュアセッションを使用できます。セキュアセッションが使用可能なのは、SGD セキュリティーサービスが有効になっている場合だけです。詳細については、「SGD サーバーへのセキュア接続」を参照してください。
Administration Console では、次の手順でユーザーセッションを一覧表示できます。
ナビゲーションビューの「セッション」タブには、アレイ内のすべての SGD サーバーで実行されているすべてのユーザーセッションが表示されます
SGD サーバーの「ユーザーセッション」タブには、その SGD サーバーでホストされているすべてのユーザーセッションが表示されます
ユーザープロファイルの「ユーザーセッション」タブには、そのユーザープロファイルに関連付けられているすべてのユーザーセッションが表示されます。
「セッション」タブと「ユーザーセッション」タブでは、ユーザーセッションを選択して終了させることができます。「ユーザーセッション」タブでは、ユーザーセッションの詳細を表示することができます。たとえば、クライアントデバイスに関して SGD Client で検出された情報です。
コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella webtopsession コマンドを使用します。
アクティブでないユーザーセッションのアイドルタイムアウト時間を設定できます。SGD Client と SGD サーバーの間の AIP 接続で指定された期間アクティビティーが何も行われない場合、ユーザーセッション自動的に終了します。SGD アレイのタイムアウトは、デフォルトでは無効になっています。
次のデバイスでのアクティビティーはアイドルタイムアウト時間に影響を与えません。
シリアルポート
スマートカード
オーディオ
「アイドルタイムアウト」属性を指定するには、Administration Console の「グローバル設定」 → 「通信」タブに移動し、「ユーザーセッションのアイドルタイムアウト」フィールドに値を入力します。
または、次のコマンドを実行します。
$ tarantella config edit --webtop-session-idle-timeout secs
ここで、secs
はタイムアウト値 (単位は秒) です。0 に設定すると、アイドル状態のユーザーセッションのタイムアウト機能はオフになります。これは、デフォルト設定です。
300 秒 (5 分) 未満のアイドルタイムアウトは設定しないでください。
この属性への変更を有効にするには、アレイ内のすべての SGD サーバーを再起動する必要があります。
アプリケーションセッションは、ユーザーがアプリケーションを起動した時点で始まり、アプリケーションを終了した時点で終わります。各アプリケーションセッションは、SGD を使って現在実行中のアプリケーションの 1 つに対応しています。
アプリケーションセッションは、アレイ内のいずれの SGD サーバーでもホストできます。ユーザーがログインしたのと同じ SGD サーバーではない場合もあります (「アレイ」を参照)。
各アプリケーションセッションには、対応するプロトコルエンジンプロセスがあります。プロトコルエンジンは、クライアントデバイスとアプリケーションサーバーの間の通信を処理します。さらに、プロトコルエンジンは、アプリケーションで使われているディスプレイプロトコルを、クライアントデバイス上で実行中の SGD Client が認識する AIP に変換します。
アプリケーションセッションの負荷分散を使って、プロトコルエンジンの負荷を、アレイ内の SGD サーバー間で分散させることができます。詳細については、「アプリケーションセッションの負荷分散」を参照してください。
アプリケーションの中には、表示されていなくても実行し続けるように設定されるものもあります。それらは再開可能なアプリケーションと呼ばれます。
再開可能なアプリケーションは、次の理由で役立ちます。
起動に時間がかかるアプリケーションを、ユーザーが SGD からログアウトしたあとも実行したままにしておくことができる
モバイルユーザーが、移動中にアプリケーションを実行したままにすることができる
ブラウザなどがクラッシュした場合に、ユーザーが容易に復旧できる
各アプリケーションオブジェクトには「アプリケーションの再開機能」属性があり、これによってアプリケーションを再開できるかどうかが決定されます。各アプリケーションは、次に示す「アプリケーションの再開機能」設定のいずれかを持ちます。
設定 | 説明 |
---|---|
使用しない | アプリケーションは、ユーザーが SGD からログアウトするときに終了します。再開可能でないアプリケーションを中断または再開することはできません。 |
ユーザーセッション中 | アプリケーションは、ユーザーが SGD からログアウトするまで実行し続けます。ユーザーはログインしている間、それらのアプリケーションを中断および再開できます。 |
一般 | アプリケーションは、ユーザーが SGD からログアウトしたあとも、実行し続けます。再度ログインした際に、「再開」ボタンをクリックすると、実行中のアプリケーションが再度表示されます。 |
アプリケーションが再開可能な場合、タイムアウトで指定されている一定期間のみ再開できます。SGD Client が突然終了したり、SGD サーバーへの接続が失われたりした場合、構成されたタイムアウトに 20 分加えたタイムアウト期間になります。
20 分間の接続タイムアウトによって、SGD サーバーは SGD Client との接続を再確立できます。この期間が経過すると、ユーザーセッションが終了します。接続タイムアウトの値を変更するには、次のコマンドを使用します。
# tarantella config edit --tarantella-config-array-restartconnectiontimeout mins
ここで、mins
は接続タイムアウト期間 (分) です。
表7.1「アプリケーションの再開機能のシナリオ」では、いくつかの一般的なシナリオにおけるアプリケーションの再開機能の動作について説明しています。
表7.1 アプリケーションの再開機能のシナリオ
シナリオ | 説明 |
---|---|
ユーザーが SGD からログアウトする | ユーザーセッションはすぐに終了します。 その後のアプリケーションセッションの動作は、次に示すように、アプリケーションオブジェクトの「アプリケーションの再開機能」設定によって異なります。
|
SGD サーバーへの接続が失われる | SGD Client と SGD サーバー間の接続が失われたことを SGD が検出し、20 分のタイムアウト期間が開始されます。 接続が 20 分以内に復元された場合は、アプリケーションセッションを再開できます。 20 分が経過すると、ユーザーセッションは終了します。その後のアプリケーションセッションの動作は、次に示すように、アプリケーションオブジェクトの「アプリケーションの再開機能」設定によって異なります。
|
SGD Client が予期せずに終了した | SGD Client が予期せずに終了したことを SGD が検出し、20 分のタイムアウト期間が開始されます。 アプリケーションの「アプリケーションの再開機能」設定が「なし」の場合は、アプリケーションセッションはすぐに終了します。それ以外の場合は、20 分のタイムアウト期間内にアプリケーションセッションを再開できます。 20 分が経過すると、ユーザーセッションは終了します。その後のアプリケーションセッションの動作は、次に示すように、アプリケーションオブジェクトの「アプリケーションの再開機能」設定によって異なります。
|
Administration Console では、次の手順でアプリケーションセッションを一覧表示できます。
SGD サーバーの「アプリケーションセッション」タブには、そのサーバーでホストされているすべてのアプリケーションセッションが表示されます。
ユーザープロファイルの「アプリケーションセッション」タブには、そのユーザープロファイルに関連付けられているすべてのアプリケーションセッションが表示されます。
アプリケーションサーバーの「アプリケーションセッション」タブには、そのアプリケーションサーバーで実行されているすべてのアプリケーションが表示されます。
「アプリケーションセッション」タブでは、各アプリケーションセッションの詳細を表示できます。また、アプリケーションセッションを終了したりシャドウィングしたりすることもできます。セッションをシャドウィングすると、管理者とユーザーが同じアプリケーションを同時に使って対話することができます。
アプリケーションセッションのシャドウィングの詳細については、「ユーザーの問題をトラブルシューティングするためのシャドウイングの使用」 を参照してください。
シャドウイングできるのは、Windows アプリケーションと X アプリケーションだけです。アプリケーションセッションを中断してはいけません。
コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella emulatorsession コマンドを使用します。
次のように、特殊な場合が 2 つあります。
匿名ユーザー。ユーザー名とパスワードを入力せずにログインするユーザーです。「匿名ユーザーの認証」を参照してください。
共有ユーザー。ゲストユーザーとも呼ばれます。同じユーザー名とパスワードを使ってログインするユーザーです。「ゲストユーザー用の共有アカウントの使用」を参照してください。
これらのユーザーを区別するために、ゲストユーザーと匿名ユーザーにはログイン時に SGD によって一時的なユーザー識別情報が割り当てられます。これは次の影響を与えます。
ユーザーが SGD に複数回ログインするとユーザーセッションが転送されません
アプリケーションの「アプリケーションの再開機能」設定にかかわらず、ユーザーセッションが終了するとすぐにアプリケーションセッションが終了します
ユーザーがログアウトしない場合は、サーバーのリソースが消費されます。
SGD の初回インストール時に、デフォルトのログフィルタに SGD サーバーのエラーがすべて記録されます。問題解決などのため、より詳細な情報が必要な場合は、追加のログフィルタを設定できます。
追加のログフィルタは次の方法で設定できます。
Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドにフィルタを入力します。各フィルタは、Return キーを押して区切る必要があります。
次のコマンドを使用します。
$ tarantella config edit --array-logfilter filter
...
複数の filter
エントリをスペースで区切り、二重引用符 ("
"
) で囲みます。
各ログフィルタの形式は次のとおりです。
component/subcomponent/severity:destination
フィルタの各部分のオプション、およびログ出力の表示方法については、以降のセクションで説明します。
ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。
コンポーネントおよびサブコンポーネントを選択することで、SGD サーバーから記録したい情報の分野を選択できます。
次の表に、使用可能なコンポーネントとサブコンポーネントの組み合わせ、および各組み合わせで得られる情報の種類について説明します。
コンポーネントとサブコンポーネント | 提供される情報 |
---|---|
| SGD サーバー構成またはローカルリポジトリ構成に加えた変更および変更の実行者に関する監査。 たとえば、これを使用して、ユーザープロファイルオブジェクトを変更したユーザーを確認できます。 |
| ユーザーセッションおよびアプリケーションセッションの開始と停止。 たとえば、これを使用して、ユーザーによるアプリケーションセッションの実行期間を確認できます。 |
| クライアントドライブマッピング (CDM) のための SGD ユーザーの認証。 たとえば、これを使用して、ユーザーの資格情報が原因で CDM が失敗しているかどうかを確認できます。 |
| CDM サービスに関する情報。 たとえば、これを使用して、クライアント接続エラーが原因で CDM が失敗しているかどうかを確認できます。 |
| アレイ全体で SGD サーバー構成を格納およびコピーする方法。 たとえば、これを使用して、グローバル設定の構成変更が SGD サーバーに適用されない理由を確認できます。 |
| メモリーおよびタイミング。 たとえば、これを使用して、SGD コマンドの実行に要した時間を確認できます。 |
| Tomcat の SOAP プロキシの SOAP コンポーネント。 たとえば、これを使用して、SOAP 要求が完了するまでにかかった時間を追跡できます。 |
| SGD 課金処理サービス。 たとえば、これを使用して、課金処理データが失われた理由を調べることができます。 |
| SGD の一般情報。 たとえば、これを使用して、DNS エラーの問題をトラブルシューティングできます。 |
| SGD サーバー構成の変更。 たとえば、これを使用して、SGD サーバー構成の変更をログに記録する、または構成が壊れているかどうかを確認することができます。 |
| SGD Client セッションハンドラ。 たとえば、これを使用して、ユーザーがアプリケーションセッションを再起動できない理由を確認できます。 |
| アクセス可能なデバイスデータへのユーザーのマッピング。 たとえば、これを使用して、ユーザーがクライアントドライブにアクセスできない理由を確認できます。 |
| Active Directory または LDAP への接続。 たとえば、これを使用して、Active Directory または LDAP のユーザーがログインできない理由を確認できます。 |
| ローカルリポジトリに関する情報。 たとえば、これを使用して、破壊されているオブジェクトやローカルリポジトリ内の不一致に関する情報を取得できます。 |
| アレイフェイルオーバーに関する情報。 たとえば、これを使えば、プライマリサーバーが使用不可能になっている SGD アレイの問題のトラブルシューティングを行えます。 |
| SGD サーバー間の通信に使用されるプロトコル。 たとえば、これを使用して、SGD サーバーが通信できない理由を確認できます。 |
| インストールおよびアップグレード。 たとえば、これを使用して、インストールに関する問題を調査できます。 |
| Windows Kerberos 認証。 たとえば、これを使用して、Active Directory のユーザーがログインできない理由を確認できます。 |
| アプリケーションの起動または再開。 たとえば、これを使用して、ユーザーがアプリケーションを起動できない理由を確認できます。 |
| ユーザーセッションおよびアプリケーションの負荷分散。 たとえば、これを使用して、アプリケーションセッションをホストする SGD サーバーが選択されていない理由を確認できます。 |
| ロギング。 たとえば、これを使用して、ログメッセージがファイルに書き込まれない理由を確認できます。 |
| SGD にログインします。 たとえば、これを使用して、ユーザーおよび使用するユーザープロファイルを認証した認証メカニズムを確認できます。 |
| SGD MUPP (MUltiplePlexing Protocol) プロトコル。 サポートから依頼された場合にのみ、このフィルタを使用する。 |
| SGD 印刷サービス。 たとえば、これを使用して、印刷ジョブが失敗する理由を確認できます。 |
| アレイ内の SGD サーバー間でのデータコピー。 たとえば、これを使用して、アレイメンバー間でデータがコピーされない理由を確認できます。 |
| SecurID RSA Authentication Manager への接続。 たとえば、これを使用して、SecurID 認証が機能しない理由を確認できます。 |
| SSL ベースのセキュア接続。 たとえば、これを使用して、SSL デーモンが実行されない理由を確認できます。 |
| SGD サーバーコンポーネント。 たとえば、これを使用して、ほかの場所には記録されない Java™ テクノロジ実行時例外などの、SGD サーバーの失敗をトラブルシューティングできます。 |
| 内部の SGD サーバーサービス。 たとえば、これを使用して、サービスが失敗する理由を確認できます。 |
| ユーザーセッション。 たとえば、これを使用して、セッションが中断に失敗する理由を確認できます。 |
| SOAP Bean インタフェース。 たとえば、これを使用して、SOAP Bean の問題を診断できます。 |
| SOAP 要求。 たとえば、これを使用して、受信した SOAP 要求をログに記録できます。 |
| アプリケーションサーバーの負荷分散。 たとえば、これを使用して、アプリケーションを起動するアプリケーションサーバーが選択されていない理由を確認できます。 |
| Windows 以外のクライアント用の Windows リモートデスクトップサービス Client Access License (CAL)。 たとえば、これを使用して、Windows 以外のクライアントが CAL を保持しない理由を確認できます。 |
| Webtop コンテンツ (Directory Services Integration を使用している場合)。 たとえば、これを使用して、アプリケーションがユーザーの Webtop に表示されない理由を確認できます。 |
各ログフィルタについて、次の重要度レベルのいずれかを選択できます。
重要度 | 説明 |
---|---|
| 致命的エラーに関する情報をログに記録します。致命的エラーが発生すると、SGD サーバーは実行を停止します。SGD の初回インストール時には、すべての致命的エラーがデフォルトでログに記録されます。 |
| 発生したすべてのエラー情報をログに記録します。SGD の初回インストール時には、すべてのエラーがデフォルトでログに記録されます。 |
| システムリソースの減少などの、発生したすべての警告に関する情報をログに記録します。SGD の初回インストール時には、すべての警告がデフォルトでログに記録されます。 |
| 情報ロギング。バグの解決や識別に役立ちます。 |
| 詳細な情報ロギング。 |
| SGD サーバー構成の変更など、選択したイベントのログを監査目的で記録します。詳細については、「ログフィルタを使用した監査」を参照してください。 |
重要度 fatalerror
の場合に、生成される情報がもっとも少なくなります。重要度 moreinfo
の場合に、生成される情報量がもっとも多くなります。
重要度レベルの選択は、累積的ではありません。たとえば、info
を選択しても、warningerror
または fatalerror
ログメッセージは表示されません。
複数の重要度レベルをログに記録する場合は、ワイルドカードを使用します。
ログの出力先として、次のいずれかを指定できます。
ログファイル
ログハンドラ
これらの出力先について以降のセクションで説明します。
ログファイルに出力する場合、次の種類のファイルに出力が可能です。
filename
.log
SGD により、このログ出力は読みやすく書式設定されます。
tarantella query errlog コマンドの実行には、この形式が必須です。このコマンドは、名前の末尾が error.log
であるログファイルだけを検索します。
filename
.jsl
SGD により、このログ出力は自動構文解析および検索に合わせて書式設定されます。
tarantella query audit コマンドの実行には、この形式が必須です。
ファイルの形式は、出力先ファイルのファイル拡張子により制御されます。
ファイル名に %%PID%%
プレースホルダーを含めることで、プロセス ID ごとに別個のログファイルを作成することもできます。
ログファイルは、/opt/tarantella/var/log
ディレクトリに出力されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。また、syslog
ログハンドラを使用することもできます (詳細については、「ログハンドラの使用」を参照)。
ログハンドラは、ログメッセージの出力先として使用される JavaBeans コンポーネントです。ログハンドラを指定している場合は、その完全名を使用する必要があります。SGDには、次のログハンドラが用意されています。
ConsoleSink。ConsoleSink ログハンドラは、ログメッセージを読みやすい形式で標準エラーに書き出します。このログハンドラは、デフォルトで有効で、すべての致命的エラーをログに記録します。
このログハンドラの完全な名前を、次に示します。
.../_beans/com.sco.tta.server.log.ConsoleSink
SyslogSink。SyslogSink ログハンドラは、ログメッセージを UNIX または Linux プラットフォームの syslog
機能に書き出します。
このログハンドラの完全な名前を、次に示します。
.../_beans/com.sco.tta.server.log.SyslogSink
次に、一般的に使用されるログフィルタの例を示します。
ユーザーログインをデバッグする:
server/login/*:login%%PID%%.log server/login/*:login%%PID%%.jsl
CDM をトラブルシューティングするには:
cdm/*/*:cdm%%PID%%.log cdm/*/*:cdm%%PID%%.jsl server/deviceservice/*:cdm%%PID%%.log server/deviceservice/*:cdm%%PID%%.jsl
印刷の問題を解決する:
server/printing/*:print%%PID%%.log server/printing/*:print%%PID%%.jsl
サーバーパフォーマンスのタイミング測定を取得する:
metrics/*/*info:metrics.log metrics/*/*info:metrics.jsl
すべての警告、エラー、および致命的エラーを syslog に送信する:
*/*/*error:.../_beans/com.sco.tta.server.log.SyslogSink
ログ出力を表示するには、次のいずれかを実行します。
.log
ファイルをビューアまたはテキストエディタで開きます
tarantella query コマンドを使用します
tarantella query コマンドを使用する場合は、次のコマンドオプションを使用します。
tarantella query errlog – 特定の SGD サーバーコンポーネントのエラーおよび致命的エラーだけを表示する場合
tarantella query audit – 人物、アプリケーション、またはアプリケーションサーバーに関するメッセージのログをすべて検索する場合
これらのコマンドを使用してログ出力を表示できるのは、ログがアーカイブされるまでです。アーカイブの構成は SGD のインストール時に行いますが、tarantella setup コマンドを実行することでいつでも設定を変更できます。
SGD では、ログフィルタを設定して次のシステムイベントを監査できます。
SGD サーバーの開始と停止
SGD セキュリティーサービスの開始と停止
ローカルリポジトリのオブジェクト設定の変更
グローバル構成と SGD サーバー構成の変更
SGD サーバーへのログインの失敗
SGD に対するログインとログアウト
アプリケーションセッションの開始と停止
これらのイベントを監査するには、*/*/*auditinfo
ログフィルタを設定する必要があります。
任意の標準出力先を使用できますが、監査情報をコマンド行から表示するためには、.jsl
ファイルに出力する必要があります。
ログフィルタの設定についての詳細は、「ログフィルタを使用した SGD サーバーのトラブルシューティング」 を参照してください。
ログの出力は、SGD サーバーが実際に実行されている場合のみ作成されます。SGD サーバーが停止している場合、UNIX システムの root ユーザーのみが監査可能なイベントを実行できます。
各イベントに関する次の情報が、ログフィルタによって記録されます。
イベントの日時
イベントの種類
イベントの結果 (成功または失敗)
イベントを実行したユーザー識別情報
イベントに関連するその他の情報 (変更された設定や値など)
ログ出力は、標準の方法を使用して表示できます。ただし、次のコマンドがもっとも役立ちます。
# tarantella query audit --format text|csv|xml --filter "filter
"
text
形式を選択した場合、SGD は画面上で読みやすい形式のログを出力しますが、これには記録されたすべての詳細情報は表示されません。csv
形式を使用すると、記録された詳細情報はすべて表示されますが、これはファイルに出力する場合のみに適しています。
「filter
」は RFC2254 に準拠する LDAP 検索フィルタです。このコマンドで、ログファイルのログフィールドから該当するエントリを検索して表示します。次の表に、監査の際に特に役立つログフィールドを示します。
ログフィールド | 説明 |
---|---|
|
log-category は監査を行う場合は常に |
| イベント発生時のシステム日時。
形式は |
| イベントの名前。 |
| イベントに関連付けられているクライアントまたはサーバーの IP アドレス。 |
| 監査可能なイベントのキーワード ID。 |
| イベントが発生した SGD サーバーのピア DNS 名。 |
| イベントのプロセス ID。 |
|
接続で使用されているセキュリティーのタイプ ( |
| イベント発生時のシステム時刻を表す UTC (Coordinated Universal Time) 時間 (ミリ秒単位)。 |
| イベントに関連付けられているオブジェクトの完全な名前。 たとえば、アプリケーションセッションを起動すると、ユーザー、アプリケーション、およびアプリケーションサーバーの名前が記録される場合があります。 |
すべてのログフィールドのリストは、/opt/tarantella/var/serverresources/schema/log.at.conf
スキーマファイルで参照できます。
すべての log-keyword と該当する log-event を次の表に示し、イベントについて説明します。
Log-Keyword | Log-Event | 説明 |
---|---|---|
|
| ユーザーがローカルリポジトリのオブジェクトの作成に失敗しました。 |
|
| ユーザーがローカルリポジトリのオブジェクトを作成しました。 |
|
| ユーザーがローカルリポジトリのオブジェクトの削除に失敗しました。 |
|
| ユーザーがローカルリポジトリのオブジェクトを削除しました。 |
|
| SGD サーバーからクライアントに対して、異なるポートへの再接続が要求されました。 |
|
| 有効にされている認証メカニズムのいずれによっても、ユーザーが認証されませんでした。 |
|
| ログインフィルタによってユーザーのログインが拒否されました。これには、特定のサーバーで現在ログインが許可されていない、ユーザーのログインが現在許可されていない、などの原因が考えられます。 |
|
| 現在、SGD サーバーは接続を受け付けていません。 |
|
| SGD サーバーであいまいなユーザーのログインがサポートされていないため、あいまいなログインが失敗しました。 |
|
| ユーザーが十分な情報を指定したため、あいまいなログインが失敗しました。 |
|
| SGD サーバーで匿名ログインがサポートされていないため、匿名ログインが失敗しました。 |
|
| 標準ポートで接続が確立されたため、セキュリティー保護された接続を要求するユーザーのログインが失敗しました。 |
|
| SGD サーバーでユーザーを解決できなかったため、ログインが失敗しました。 |
|
| SGD サーバーで予測外のログイン結果を処理できなかったため、ログインが失敗しました。 |
|
| ユーザーのユーザーセッションが開始されました。 |
|
| ユーザーのユーザーセッションが停止されました。 |
|
| ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの構成の変更に失敗しました。 |
|
| ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの構成の変更を行いました。 |
|
| ユーザーがローカルリポジトリのオブジェクトの名前変更に失敗しました。 |
|
| ユーザーがローカルリポジトリのオブジェクトの名前を変更しました。 |
|
| SGD サーバーが起動しました。 |
|
| SGD サーバーが停止しました。 |
|
| ユーザーのアプリケーションセッションが停止されました。 |
|
| ユーザーのアプリケーションセッションが開始されました。 |
|
| SGD セキュリティー (SSL) サービスが開始しました。 |
|
| SGD セキュリティー (SSL) サービスが停止しました。 |
SGD を初めてインストールした時点でのデフォルトのログフィルタでは、プロトコルエンジン (PE) のすべてのエラーが記録されます。PE のアクティビティーに関するより詳細な情報を取得する必要がある場合には、追加の PE ログフィルタを設定できます。
PE ログフィルタの設定は、個々の PE に対してと、プロトコルエンジンマネージャー (PE マネージャー) プロセスに対して行えます。PE ログフィルタを設定するには、次の表に示す属性のいずれかを設定します。
PE フィルタ属性 | プロトコルエンジン |
---|---|
| PE マネージャー |
| 実行プロトコルエンジン |
| X プロトコルエンジン |
| 文字型プロトコルエンジン |
| 印刷プロトコルエンジン |
| チャネルプロトコルエンジン |
PE ログフィルタの設定はコマンド行からしか行えません。次のコマンドを使用します。
$ tarantella config edit--PE-filter-attribute
filter...
ここで、PE-filter-attribute
は構成する PE フィルタ属性を、 filter
はログフィルタを、それぞれ定義します。複数のログフィルタを定義する場合には、二重引用符を使って各 filter パラメータを区切ります。
各ログフィルタの形式は次のとおりです。
component/subcomponent/severity
次の表に、PE ロギングで使用可能なコンポーネント名を示します。
プロトコルエンジン | コンポーネント |
---|---|
PE マネージャー |
|
実行プロトコルエンジン |
|
X プロトコルエンジン |
|
文字型プロトコルエンジン |
|
印刷プロトコルエンジン |
|
チャネルプロトコルエンジン |
|
サブコンポーネントについては、*
と入力すると、すべてのサブコンポーネントの情報が含められます。
選択可能な重要度レベルは、次のとおりです。
*
– すべてのエラーおよび警告メッセージを含めます。
*info
– info
、moreinfo
、および auditinfo
メッセージを含めます。
*error
– error
、fatalerror
、および warningerror
メッセージを含めます。これはデフォルトの重要度です。
実行、X、文字型、印刷、およびチャネル PE ログフィルタに対する変更は、新しい PE の起動時に有効になります。
PE マネージャーログフィルタに対する変更を有効にするには、SGD サーバーを再起動する必要があります。
ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。この方法の詳細については、「PE ログフィルタのリセット」を参照してください。
次に、PE ログフィルタの使用例をいくつか示します。
X および Windows アプリケーションの CDM のトラブルシューティングを行うには、次のようにします。
--tarantella-config-xpeconfig-logfilter "xpe/cdm/*"
X および Windows アプリケーションの問題のトラブルシューティングを行うには、次のようにします。
--tarantella-config-xpeconfig-logfilter "xpe/*/*" "pem/*/*"
アプリケーション起動のトラブルシューティングを行うには、まず、「アプリケーションが起動しない場合」の説明に従って SGD ログインスクリプトでのデバッグを有効にする必要があります。次に、実行プロトコルエンジンのログフィルタを次のように設定します。
--tarantella-config-execpeconfig-logfilter "execpe/*/*"
execpe
、xpe
、tpe
、ppe
、および cpe
ログフィルタで pem/*
フィルタを使用すると、そのプロトコルエンジンに関係する PE マネージャーメッセージが表示されます。
PE ログファイルのファイル名拡張子は、.log
です。SGD により、このタイプのログ出力は読みやすく書式設定されます。
PE コンポーネントの名前とプロセス ID が含まれる PE ログファイル名。たとえば、プロセス ID 4512 で実行されている PE マネージャーメッセージは、pemanager4512.log
です。
重要度が error
、fatalerror
、または warningerror
のエラーメッセージは、error.log
で終わる名前を持つ PE ログファイルに格納されます。たとえば、プロセス ID 2256 で実行されている文字型プロトコルエンジンのエラーメッセージは、cpe2256_error.log
という名前のファイルに格納されます。このようなファイルは、error.log
で終わる名前を持つログファイルだけを検索する tarantella query errlog
コマンドによって使用されます。
PE ログフィルタ出力は自動的に、SGD ホスト上の /opt/tarantella/var/log
ディレクトリ内のログファイルに格納されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。
PE ログを表示するには、次のいずれかを行います。
.log
ファイルをビューアまたはテキストエディタで開きます。
アレイ内の各 SGD サーバーの .log
ファイルには、その特定の SGD サーバーで実行されている PE のメッセージが含まれています。
tarantella query errorlog コマンドを使って PE のエラーメッセージを表示します。
このコマンドを使えば、アレイ内のすべての PE エラーログを検索できます。
たとえば、アレイ内のすべての SGD サーバーの X プロトコルエンジンのエラーメッセージを表示するには、次のコマンドを使用します。
$ tarantella query errlog xpe
たとえば、SGD サーバー boston.example.com の X プロトコルエンジンのエラーメッセージを表示するには、次のコマンドを使用します。
$ tarantella query errlog xpe --server boston.example.com
これらのコマンドを使用してログ出力を表示できるのは、ログがアーカイブされるまでです。アーカイブの構成は SGD のインストール時に行いますが、tarantella setup コマンドを実行することでいつでも設定を変更できます。
ログフィルタを使用すると大量のデータが作成される可能性があるため、不要になったフィルタはリセットしてデフォルト設定に戻すことをお勧めします。
PE ログフィルタのデフォルト構成では、PE コンポーネントのすべてのサブコンポーネントに対して重要度 *error
が設定されます。次の表に、各ログフィルタのデフォルト設定を示します。
プロトコルエンジン | ログフィルタのデフォルト設定 |
---|---|
PE マネージャー |
|
実行プロトコルエンジン |
|
X プロトコルエンジン |
|
文字型プロトコルエンジン |
|
印刷プロトコルエンジン |
|
チャネルプロトコルエンジン |
|
たとえば、X プロトコルエンジンのログフィルタをリセットするには、次のコマンドを使用します。
$ tarantella config edit \ --tarantella-config-xpeconfig-logfilter "xpe/*/*error" "pem/*/*error"
SGD Web サーバーのメッセージは次のログ内に記録されます。
Tomcat JSP テクノロジコンテナのログ
Apache Web サーバーのログ
SGD Web サーバーの Tomcat JSP テクノロジコンテナコンポーネントのログメッセージは、SGD ホスト上の /opt/tarantella/webserver/tomcat/
ディレクトリ内の次のファイルに書き込まれます。
tomcat-version
/logs
catalina.out
– このログファイルがいっぱいになるか Tomcat JSP テクノロジコンテナが再起動されると、このファイルのローテーションが行われ、その内容が catalina.out.sav
の末尾に追加されます。
localhost_log.
– これは日次ログファイルであり、date
.txtdate
はメッセージが記録された日付です。
これらのログファイルはテキストエディタを使って読むことができます。
Tomcat JSP テクノロジコンテナのログファイルを使えば、次の各項目に関する問題を診断できます。
Tomcat JSP テクノロジコンテナの起動と停止
AJP 1.3 Connector の起動
SGD Webtop Web アプリケーションのロード
Webtop JSP ソフトウェアの例外エラー
Tomcat JSP テクノロジコンテナのロギングプロパティーの構成は、/opt/tarantella/webserver/tomcat/
ファイル内で行います。Tomcat JSP テクノロジコンテナのロギングを構成する方法については、Tomcat ドキュメントを参照してください。
tomcat-version
/conf/logging.properties
SGD Web サーバーの Apache Web サーバーコンポーネントのログメッセージは、SGD ホスト上の /opt/tarantella/webserver/apache/
ディレクトリ内の次のファイルに書き込まれます。
apache-version
/logs
errors_log
– Apache Web サーバーのエラーメッセージをロギングします
access_log
– Apache Web サーバーによって処理されたすべてのアクセス要求をロギングします
これらのログファイルはテキストエディタを使って読むことができます。
Apache Web サーバーのログファイルを使えば、次の各項目に関する問題を診断できます。
Apache Web サーバーの起動と停止
SGD Webtop ページのクライアント要求
Web 認証
これらのログファイルについては、Apache ドキュメントを参照してください。
SGD Client のログメッセージはデフォルトで、クライアントデバイス上の次の場所に格納されます。
Microsoft Windows クライアントデバイス。ユーザー固有の書き込み可能ディレクトリにある tcc.txt
というファイル。
Microsoft Windows XP プラットフォームでの例を次に示します。
C:\Documents and Settings\
username
\Local Settings\Application Data\Sun\SSGD
Microsoft Windows 7 プラットフォームの場合。例:
C:\Users\
username
\AppData\Local\Temp\Sun\SSGD
実際の場所は、ユーザーの特権、オペレーティングシステム、および使用されている Java Plug-in ソフトウェアのバージョンによって異なります。
tcc.txt
ファイルの内容はテキストエディタを使って表示できます。
UNIX、Linux、または Mac OS X プラットフォームのクライアントデバイス。クライアントデバイスのシステムログの場所。
Oracle Linux プラットフォームでの例:
/var/log/messages
Oracle Solaris プラットフォームでの例:
/var/adm/messages
Mac OS X プラットフォームでの例:
/var/log/system.log
ユーザーのクライアントデバイス上にあるシステムログは、一覧表示したものと異なる場所にある場合があります。一部のクライアントプラットフォームでは、システムログを表示するための権限が必要です。
SGD Client を手動で起動したときに -logdir
コマンド行引数を使用すれば、ユーザーはデフォルトのログディレクトリをオーバーライドできます。この場合、指定されたディレクトリの場所に tcc.txt
ファイルが作成されます。
SGD Client を手動で起動するときに -logdir
引数が指定されない場合は、デフォルトのログディレクトリが使用されます。
SGD Client のログファイルを使えば、次の各項目に関する問題を診断できます。
SGD Client および SGD Client Helper の起動
SGD Webtop ページのロード
CDM、印刷、スマートカードサービスなどのクライアントデバイス
SGD Client と SGD サーバー間の接続
SGD Client メッセージのロギングレベルを構成するには、クライアントプロファイル内の「ロギングレベル」設定を変更します。使用可能なロギングレベルを冗長レベルの低い順に並べたものを、次に示します。
ログなし – SGD Client のロギングを無効にします。
エラーのみ – エラーメッセージを記録します。これは、デフォルト設定です。
エラーと警告のみ – エラーメッセージと警告メッセージを記録します。
すべて – エラーメッセージ、警告メッセージ、情報メッセージなど、すべてのメッセージを記録します。
クライアントデバイスの情報は、ユーザーの Webtop の「情報」 → 「詳細な診断」ページに表示されます。
管理者は Administration Console を使って、あるユーザーセッションのクライアントデバイス情報を表示できます。「ユーザーセッションリスト」テーブルでユーザーセッションを選択し、「詳細の表示」ボタンをクリックしてその詳細情報を表示します。