7.4. 監視とロギング

このセクションでは、SGD データストア、ユーザーアクティビティーの監視方法、およびロギングの構成方法について説明します。

このセクションの内容は、次のとおりです。

7.4.1. SGD データストア

アレイ内の SGD サーバーは情報を共有します。各 SGD サーバーが知っている内容は、次のとおりです。

  • 設定済みのアプリケーションと、それらのアプリケーションの実行元となるアプリケーションサーバー

  • アプリケーションにアクセス可能なユーザー

  • SGD サーバーにログインしたユーザー

  • ユーザーが実行しているアプリケーション

情報のコレクションはデータストアと呼ばれます。

ユーザー、アプリケーション、アプリケーションサーバー、および Webtop に関する情報はディスク上のローカルリポジトリ内に格納されます。ユーザーセッションとアプリケーションセッションに関する情報は、メモリー内に格納されます。

データストアは、コマンド行やログファイルで表示および使用されるネームスペースに編成されます。一般的な構造は、.../namespace/name-within-namespace です。... はデータストアのルートを表します。ネームスペースは DNS など、情報のソースを示します。ネームスペースのあとに、そのネームスペースに適した任意の命名規則に従って名前が記述されます。名前はファイルシステムのパスと同様に記述されます (スラッシュで区切られたトップダウン形式)。

次に、一般的に使用されるネームスペースをいくつか示します。

ネームスペース

説明

ローカル

ローカルリポジトリ内の SGD オブジェクト

.../_ens/o=例/ou=Marketing/cn=Cust-o-Dat

LDAP

LDAP ディレクトリにあるオブジェクト

.../_service/sco/tta/ldapcache/cn=Cust-o-Dat,ou=Marketing,o=例

DNS

ネットワークに接続しているマシン

.../_dns/verona.example.com

7.4.2. ユーザーセッションとアプリケーションセッション

このセクションでは、SGD でのユーザーセッションとアプリケーションセッションの違いについて説明します。Administration Console とコマンド行を使ってユーザーセッションとアプリケーションセッションの監視や制御を行う方法についても説明します。

このセクションの内容は、次のとおりです。

7.4.2.1. ユーザーセッション

ユーザーセッションは、ユーザーが SGD にログインした時点で始まり、ユーザーが SGD からログアウトした時点で終わります。ユーザーセッションは、ユーザーがログインした SGD サーバーによってホストされます。ユーザーが入力したユーザー名とパスワードが、ユーザーのタイプを決定します。ユーザー認証の詳細については、2章ユーザー認証 を参照してください。

すでにユーザーセッションが開かれている場合にユーザーがログインすると、ユーザーセッションは新しい SGD サーバーに転送され、古いセッションは終了します。これは、セッションの移動またはセッションの乗っ取りと呼ばれることがあります。

ユーザーセッションには、標準セッションまたはセキュアセッションを使用できます。セキュアセッションが使用可能なのは、SGD セキュリティーサービスが有効になっている場合だけです。詳細については、「SGD サーバーへのセキュア接続」を参照してください。

Administration Console では、次の手順でユーザーセッションを一覧表示できます。

  • ナビゲーションビューの「セッション」タブには、アレイ内のすべての SGD サーバーで実行されているすべてのユーザーセッションが表示されます

  • SGD サーバーの「ユーザーセッション」タブには、その SGD サーバーでホストされているすべてのユーザーセッションが表示されます

  • ユーザープロファイルの「ユーザーセッション」タブには、そのユーザープロファイルに関連付けられているすべてのユーザーセッションが表示されます。

「セッション」タブと「ユーザーセッション」タブでは、ユーザーセッションを選択して終了させることができます。「ユーザーセッション」タブでは、ユーザーセッションの詳細を表示することができます。たとえば、クライアントデバイスに関して SGD Client で検出された情報です。

コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella webtopsession コマンドを使用します。

7.4.2.1.1. アイドル状態のユーザーセッションのタイムアウト

アクティブでないユーザーセッションのアイドルタイムアウト時間を設定できます。SGD Client と SGD サーバーの間の AIP 接続で指定された期間アクティビティーが何も行われない場合、ユーザーセッション自動的に終了します。SGD アレイのタイムアウトは、デフォルトでは無効になっています。

次のデバイスでのアクティビティーはアイドルタイムアウト時間に影響を与えません。

  • シリアルポート

  • スマートカード

  • オーディオ

「アイドルタイムアウト」属性を指定するには、Administration Console の「グローバル設定」 → 「通信」タブに移動し、「ユーザーセッションのアイドルタイムアウト」フィールドに値を入力します。

または、次のコマンドを実行します。

$ tarantella config edit --webtop-session-idle-timeout secs

ここで、secs はタイムアウト値 (単位は秒) です。0 に設定すると、アイドル状態のユーザーセッションのタイムアウト機能はオフになります。これは、デフォルト設定です。

注意

300 秒 (5 分) 未満のアイドルタイムアウトは設定しないでください。

この属性への変更を有効にするには、アレイ内のすべての SGD サーバーを再起動する必要があります。

7.4.2.2. アプリケーションセッション

アプリケーションセッションは、ユーザーがアプリケーションを起動した時点で始まり、アプリケーションを終了した時点で終わります。各アプリケーションセッションは、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 コマンドを使用します。

7.4.2.3. 匿名ユーザーと共有ユーザー

次のように、特殊な場合が 2 つあります。

これらのユーザーを区別するために、ゲストユーザーと匿名ユーザーにはログイン時に SGD によって一時的なユーザー識別情報が割り当てられます。これは次の影響を与えます。

  • ユーザーが SGD に複数回ログインするとユーザーセッションが転送されません

  • アプリケーションの「アプリケーションの再開機能」設定にかかわらず、ユーザーセッションが終了するとすぐにアプリケーションセッションが終了します

  • ユーザーがログアウトしない場合は、サーバーのリソースが消費されます。

7.4.3. ログフィルタを使用した SGD サーバーのトラブルシューティング

SGD の初回インストール時に、デフォルトのログフィルタに SGD サーバーのエラーがすべて記録されます。問題解決などのため、より詳細な情報が必要な場合は、追加のログフィルタを設定できます。

追加のログフィルタは次の方法で設定できます。

  • Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドにフィルタを入力します。各フィルタは、Return キーを押して区切る必要があります。

  • 次のコマンドを使用します。

    $ tarantella config edit --array-logfilter filter...
    

    複数の filter エントリをスペースで区切り、二重引用符 (" ") で囲みます。

各ログフィルタの形式は次のとおりです。

component/subcomponent/severity:destination

フィルタの各部分のオプション、およびログ出力の表示方法については、以降のセクションで説明します。

注記

ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。

7.4.3.1. コンポーネントとサブコンポーネントの選択

コンポーネントおよびサブコンポーネントを選択することで、SGD サーバーから記録したい情報の分野を選択できます。

次の表に、使用可能なコンポーネントとサブコンポーネントの組み合わせ、および各組み合わせで得られる情報の種類について説明します。

コンポーネントとサブコンポーネント

提供される情報

audit/glue

SGD サーバー構成またはローカルリポジトリ構成に加えた変更および変更の実行者に関する監査。

たとえば、これを使用して、ユーザープロファイルオブジェクトを変更したユーザーを確認できます。

audit/session

ユーザーセッションおよびアプリケーションセッションの開始と停止。

たとえば、これを使用して、ユーザーによるアプリケーションセッションの実行期間を確認できます。

cdm/audit

クライアントドライブマッピング (CDM) のための SGD ユーザーの認証。

たとえば、これを使用して、ユーザーの資格情報が原因で CDM が失敗しているかどうかを確認できます。

cdm/server

CDM サービスに関する情報。

たとえば、これを使用して、クライアント接続エラーが原因で CDM が失敗しているかどうかを確認できます。

common/config

アレイ全体で SGD サーバー構成を格納およびコピーする方法。

たとえば、これを使用して、グローバル設定の構成変更が SGD サーバーに適用されない理由を確認できます。

metrics/glue

メモリーおよびタイミング。

たとえば、これを使用して、SGD コマンドの実行に要した時間を確認できます。

metrics/soap

Tomcat の SOAP プロキシの SOAP コンポーネント。

たとえば、これを使用して、SOAP 要求が完了するまでにかかった時間を追跡できます。

server/billing

SGD 課金処理サービス。

たとえば、これを使用して、課金処理データが失われた理由を調べることができます。

server/common

SGD の一般情報。

たとえば、これを使用して、DNS エラーの問題をトラブルシューティングできます。

server/config

SGD サーバー構成の変更。

たとえば、これを使用して、SGD サーバー構成の変更をログに記録する、または構成が壊れているかどうかを確認することができます。

server/csh

SGD Client セッションハンドラ。

たとえば、これを使用して、ユーザーがアプリケーションセッションを再起動できない理由を確認できます。

server/deviceservice

アクセス可能なデバイスデータへのユーザーのマッピング。

たとえば、これを使用して、ユーザーがクライアントドライブにアクセスできない理由を確認できます。

server/directoryservices

Active Directory または LDAP への接続。

たとえば、これを使用して、Active Directory または LDAP のユーザーがログインできない理由を確認できます。

server/diskds

ローカルリポジトリに関する情報。

たとえば、これを使用して、破壊されているオブジェクトやローカルリポジトリ内の不一致に関する情報を取得できます。

server/failover

アレイフェイルオーバーに関する情報。

たとえば、これを使えば、プライマリサーバーが使用不可能になっている SGD アレイの問題のトラブルシューティングを行えます。

server/glue

SGD サーバー間の通信に使用されるプロトコル。

たとえば、これを使用して、SGD サーバーが通信できない理由を確認できます。

server/install

インストールおよびアップグレード。

たとえば、これを使用して、インストールに関する問題を調査できます。

server/kerberos

Windows Kerberos 認証。

たとえば、これを使用して、Active Directory のユーザーがログインできない理由を確認できます。

server/launch

アプリケーションの起動または再開。

たとえば、これを使用して、ユーザーがアプリケーションを起動できない理由を確認できます。

server/loadbalancing

ユーザーセッションおよびアプリケーションの負荷分散。

たとえば、これを使用して、アプリケーションセッションをホストする SGD サーバーが選択されていない理由を確認できます。

server/logging

ロギング。

たとえば、これを使用して、ログメッセージがファイルに書き込まれない理由を確認できます。

server/login

SGD にログインします。

たとえば、これを使用して、ユーザーおよび使用するユーザープロファイルを認証した認証メカニズムを確認できます。

server/mupp

SGD MUPP (MUltiplePlexing Protocol) プロトコル。

サポートから依頼された場合にのみ、このフィルタを使用する。

server/printing

SGD 印刷サービス。

たとえば、これを使用して、印刷ジョブが失敗する理由を確認できます。

server/replication

アレイ内の SGD サーバー間でのデータコピー。

たとえば、これを使用して、アレイメンバー間でデータがコピーされない理由を確認できます。

server/securid

SecurID RSA Authentication Manager への接続。

たとえば、これを使用して、SecurID 認証が機能しない理由を確認できます。

server/security

SSL ベースのセキュア接続。

たとえば、これを使用して、SSL デーモンが実行されない理由を確認できます。

server/server

SGD サーバーコンポーネント。

たとえば、これを使用して、ほかの場所には記録されない Java™ テクノロジ実行時例外などの、SGD サーバーの失敗をトラブルシューティングできます。

server/services

内部の SGD サーバーサービス。

たとえば、これを使用して、サービスが失敗する理由を確認できます。

server/session

ユーザーセッション。

たとえば、これを使用して、セッションが中断に失敗する理由を確認できます。

server/soap

SOAP Bean インタフェース。

たとえば、これを使用して、SOAP Bean の問題を診断できます。

server/soapcommands

SOAP 要求。

たとえば、これを使用して、受信した SOAP 要求をログに記録できます。

server/tier3loadbalancing

アプリケーションサーバーの負荷分散。

たとえば、これを使用して、アプリケーションを起動するアプリケーションサーバーが選択されていない理由を確認できます。

server/tscal

Windows 以外のクライアント用の Windows リモートデスクトップサービス Client Access License (CAL)。

たとえば、これを使用して、Windows 以外のクライアントが CAL を保持しない理由を確認できます。

server/webtop

Webtop コンテンツ (Directory Services Integration を使用している場合)。

たとえば、これを使用して、アプリケーションがユーザーの Webtop に表示されない理由を確認できます。

7.4.3.2. 重要度の選択

各ログフィルタについて、次の重要度レベルのいずれかを選択できます。

重要度

説明

fatalerror

致命的エラーに関する情報をログに記録します。致命的エラーが発生すると、SGD サーバーは実行を停止します。SGD の初回インストール時には、すべての致命的エラーがデフォルトでログに記録されます。

error

発生したすべてのエラー情報をログに記録します。SGD の初回インストール時には、すべてのエラーがデフォルトでログに記録されます。

warningerror

システムリソースの減少などの、発生したすべての警告に関する情報をログに記録します。SGD の初回インストール時には、すべての警告がデフォルトでログに記録されます。

info

情報ロギング。バグの解決や識別に役立ちます。

moreinfo

詳細な情報ロギング。

auditinfo

SGD サーバー構成の変更など、選択したイベントのログを監査目的で記録します。詳細については、「ログフィルタを使用した監査」を参照してください。

重要度 fatalerror の場合に、生成される情報がもっとも少なくなります。重要度 moreinfo の場合に、生成される情報量がもっとも多くなります。

重要度レベルの選択は、累積的ではありません。たとえば、info を選択しても、warningerror または fatalerror ログメッセージは表示されません。

複数の重要度レベルをログに記録する場合は、ワイルドカードを使用します。

7.4.3.2.1. ワイルドカードの使用

ワイルドカード (*) を使用して、複数のコンポーネント、サブコンポーネント、および重要度に一致させることができます。

たとえば、すべての警告、エラー、および致命的エラーメッセージを印刷用としてログに記録する場合、server/printing/*error ログフィルタを使用できます。

注記

コマンド行でワイルドカードを使用する場合は、フィルタを引用符で囲んで、シェルにより展開されないようにする必要があります。

7.4.3.3. 出力先の選択

ログの出力先として、次のいずれかを指定できます。

  • ログファイル

  • ログハンドラ

これらの出力先について以降のセクションで説明します。

7.4.3.3.1. ログファイルの使用

ログファイルに出力する場合、次の種類のファイルに出力が可能です。

  • filename.log

    SGD により、このログ出力は読みやすく書式設定されます。

    tarantella query errlog コマンドの実行には、この形式が必須です。このコマンドは、名前の末尾が error.log であるログファイルだけを検索します。

  • filename.jsl

    SGD により、このログ出力は自動構文解析および検索に合わせて書式設定されます。

    tarantella query audit コマンドの実行には、この形式が必須です。

ファイルの形式は、出力先ファイルのファイル拡張子により制御されます。

ファイル名に %%PID%% プレースホルダーを含めることで、プロセス ID ごとに別個のログファイルを作成することもできます。

ログファイルは、/opt/tarantella/var/log ディレクトリに出力されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。また、syslog ログハンドラを使用することもできます (詳細については、「ログハンドラの使用」を参照)。

7.4.3.3.2. ログハンドラの使用

ログハンドラは、ログメッセージの出力先として使用される JavaBeans コンポーネントです。ログハンドラを指定している場合は、その完全名を使用する必要があります。SGDには、次のログハンドラが用意されています。

  • ConsoleSink。ConsoleSink ログハンドラは、ログメッセージを読みやすい形式で標準エラーに書き出します。このログハンドラは、デフォルトで有効で、すべての致命的エラーをログに記録します。

    このログハンドラの完全な名前を、次に示します。

    .../_beans/com.sco.tta.server.log.ConsoleSink
  • SyslogSink。SyslogSink ログハンドラは、ログメッセージを UNIX または Linux プラットフォームの syslog 機能に書き出します。

    このログハンドラの完全な名前を、次に示します。

    .../_beans/com.sco.tta.server.log.SyslogSink

7.4.3.4. ログフィルタの使用例

次に、一般的に使用されるログフィルタの例を示します。

  • ユーザーログインをデバッグする:

    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

7.4.3.5. ログ出力の表示

ログ出力を表示するには、次のいずれかを実行します。

  • .log ファイルをビューアまたはテキストエディタで開きます

  • tarantella query コマンドを使用します

tarantella query コマンドを使用する場合は、次のコマンドオプションを使用します。

  • tarantella query errlog – 特定の SGD サーバーコンポーネントのエラーおよび致命的エラーだけを表示する場合

  • tarantella query audit – 人物、アプリケーション、またはアプリケーションサーバーに関するメッセージのログをすべて検索する場合

注記

これらのコマンドを使用してログ出力を表示できるのは、ログがアーカイブされるまでです。アーカイブの構成は SGD のインストール時に行いますが、tarantella setup コマンドを実行することでいつでも設定を変更できます。

7.4.4. ログフィルタを使用した監査

SGD では、ログフィルタを設定して次のシステムイベントを監査できます。

  • SGD サーバーの開始と停止

  • SGD セキュリティーサービスの開始と停止

  • ローカルリポジトリのオブジェクト設定の変更

  • グローバル構成と SGD サーバー構成の変更

  • SGD サーバーへのログインの失敗

  • SGD に対するログインとログアウト

  • アプリケーションセッションの開始と停止

これらのイベントを監査するには、*/*/*auditinfo ログフィルタを設定する必要があります。

任意の標準出力先を使用できますが、監査情報をコマンド行から表示するためには、.jsl ファイルに出力する必要があります。

ログフィルタの設定についての詳細は、「ログフィルタを使用した SGD サーバーのトラブルシューティング」 を参照してください。

注記

ログの出力は、SGD サーバーが実際に実行されている場合のみ作成されます。SGD サーバーが停止している場合、UNIX システムの root ユーザーのみが監査可能なイベントを実行できます。

各イベントに関する次の情報が、ログフィルタによって記録されます。

  • イベントの日時

  • イベントの種類

  • イベントの結果 (成功または失敗)

  • イベントを実行したユーザー識別情報

  • イベントに関連するその他の情報 (変更された設定や値など)

7.4.4.1. 監査ログ情報の表示

ログ出力は、標準の方法を使用して表示できます。ただし、次のコマンドがもっとも役立ちます。

# tarantella query audit --format text|csv|xml --filter "filter"

text 形式を選択した場合、SGD は画面上で読みやすい形式のログを出力しますが、これには記録されたすべての詳細情報は表示されません。csv 形式を使用すると、記録された詳細情報はすべて表示されますが、これはファイルに出力する場合のみに適しています。

filter」は RFC2254 に準拠する LDAP 検索フィルタです。このコマンドで、ログファイルのログフィールドから該当するエントリを検索して表示します。次の表に、監査の際に特に役立つログフィールドを示します。

ログフィールド

説明

log-category

log-category は監査を行う場合は常に *auditinfo ですが、任意の標準ログフィルタのコンポーネント/サブコンポーネント/重要度の設定にすることができます。

log-date

イベント発生時のシステム日時。

形式は yyyy/MM/dd HH:mm:ss.SSS です。

log-event

イベントの名前。

log-ip-address

イベントに関連付けられているクライアントまたはサーバーの IP アドレス。

log-keyword

監査可能なイベントのキーワード ID。

log-localhost

イベントが発生した SGD サーバーのピア DNS 名。

log-pid

イベントのプロセス ID。

log-security-type

接続で使用されているセキュリティーのタイプ (std または ssl)。

log-systime

イベント発生時のシステム時刻を表す UTC (Coordinated Universal Time) 時間 (ミリ秒単位)。

log-tfn-name

イベントに関連付けられているオブジェクトの完全な名前。

たとえば、アプリケーションセッションを起動すると、ユーザー、アプリケーション、およびアプリケーションサーバーの名前が記録される場合があります。

注記

すべてのログフィールドのリストは、/opt/tarantella/var/serverresources/schema/log.at.conf スキーマファイルで参照できます。

すべての log-keyword と該当する log-event を次の表に示し、イベントについて説明します。

Log-Keyword

Log-Event

説明

createFailure

createFailure

ユーザーがローカルリポジトリのオブジェクトの作成に失敗しました。

createSuccess

createSuccess

ユーザーがローカルリポジトリのオブジェクトを作成しました。

deleteFailure

deleteFailure

ユーザーがローカルリポジトリのオブジェクトの削除に失敗しました。

deleteSuccess

deleteSuccess

ユーザーがローカルリポジトリのオブジェクトを削除しました。

loginFailure

loginResultReconnect

SGD サーバーからクライアントに対して、異なるポートへの再接続が要求されました。

loginFailure

loginResultFailed

有効にされている認証メカニズムのいずれによっても、ユーザーが認証されませんでした。

loginFailure

loginResultRejected

ログインフィルタによってユーザーのログインが拒否されました。これには、特定のサーバーで現在ログインが許可されていない、ユーザーのログインが現在許可されていない、などの原因が考えられます。

loginFailure

loginResultDisabled

現在、SGD サーバーは接続を受け付けていません。

loginFailure

loginResultNoAmbig

SGD サーバーであいまいなユーザーのログインがサポートされていないため、あいまいなログインが失敗しました。

loginFailure

loginResultAmbiguous

ユーザーが十分な情報を指定したため、あいまいなログインが失敗しました。

loginFailure

loginResultAnonymous

SGD サーバーで匿名ログインがサポートされていないため、匿名ログインが失敗しました。

loginFailure

loginResultNoSecurity

標準ポートで接続が確立されたため、セキュリティー保護された接続を要求するユーザーのログインが失敗しました。

loginFailure

loginResultUnresolveable

SGD サーバーでユーザーを解決できなかったため、ログインが失敗しました。

loginFailure

loginResultUnknown

SGD サーバーで予測外のログイン結果を処理できなかったため、ログインが失敗しました。

loginSuccess

webtopSessionStartedDetails

ユーザーのユーザーセッションが開始されました。

logout

webtopSessionEndedDetails

ユーザーのユーザーセッションが停止されました。

modifyFailure

modifyFailure

ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの構成の変更に失敗しました。

modifySuccess

modifySuccess

ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの構成の変更を行いました。

renameFailure

renameFailure

ユーザーがローカルリポジトリのオブジェクトの名前変更に失敗しました。

renameSuccess

renameSuccess

ユーザーがローカルリポジトリのオブジェクトの名前を変更しました。

serverStart

serverStart

SGD サーバーが起動しました。

serverStop

serverStop

SGD サーバーが停止しました。

sessionEnded

sessionEndedDetails

ユーザーのアプリケーションセッションが停止されました。

sessionStarted

sessionStartedDetails

ユーザーのアプリケーションセッションが開始されました。

sslStart

securitySSLStart

SGD セキュリティー (SSL) サービスが開始しました。

sslStop

securitySSLStop

SGD セキュリティー (SSL) サービスが停止しました。

7.4.4.2. ログフィルタを使用した監査の例

失敗したログインを検索するには、次のフィルタを使用します。

--filter "(&(log-category=*auditinfo)(log-keyword=loginFailure))"

SGD サーバーの構成に対する、管理者 Bill Orange による変更を検索するには、次のフィルタを使用します。

 --filter "(&(log-category=*auditinfo)(log-keyword=modifySuccess)
 (log-tfn-name=.../ens/o=例/ou=IT/cn=Bill Orange))"

7.4.5. ログフィルタを使用したプロトコルエンジンの問題解決

SGD を初めてインストールした時点でのデフォルトのログフィルタでは、プロトコルエンジン (PE) のすべてのエラーが記録されます。PE のアクティビティーに関するより詳細な情報を取得する必要がある場合には、追加の PE ログフィルタを設定できます。

PE ログフィルタの設定は、個々の PE に対してと、プロトコルエンジンマネージャー (PE マネージャー) プロセスに対して行えます。PE ログフィルタを設定するには、次の表に示す属性のいずれかを設定します。

PE フィルタ属性

プロトコルエンジン

--tarantella-config-auxserver-logfilter

PE マネージャー

--tarantella-config-execpeconfig-logfilter

実行プロトコルエンジン

--tarantella-config-xpeconfig-logfilter

X プロトコルエンジン

--tarantella-config-tpeconfig-logfilter

文字型プロトコルエンジン

--tarantella-config-ppeconfig-logfilter

印刷プロトコルエンジン

--tarantella-config-cpeconfig-logfilter

チャネルプロトコルエンジン

PE ログフィルタの設定はコマンド行からしか行えません。次のコマンドを使用します。

$ tarantella config edit --PE-filter-attribute filter...

ここで、PE-filter-attribute は構成する PE フィルタ属性を、 filter はログフィルタを、それぞれ定義します。複数のログフィルタを定義する場合には、二重引用符を使って各 filter パラメータを区切ります。

各ログフィルタの形式は次のとおりです。

component/subcomponent/severity

次の表に、PE ロギングで使用可能なコンポーネント名を示します。

プロトコルエンジン

コンポーネント

PE マネージャー

pem

proxy

実行プロトコルエンジン

execpe

launchhelper

X プロトコルエンジン

xpe

pem

文字型プロトコルエンジン

tpe

pem

印刷プロトコルエンジン

ppe

pem

チャネルプロトコルエンジン

cpe

pem

サブコンポーネントについては、* と入力すると、すべてのサブコンポーネントの情報が含められます。

選択可能な重要度レベルは、次のとおりです。

  • * – すべてのエラーおよび警告メッセージを含めます。

  • *infoinfomoreinfo、および auditinfo メッセージを含めます。

  • *errorerrorfatalerror、および warningerror メッセージを含めます。これはデフォルトの重要度です。

実行、X、文字型、印刷、およびチャネル PE ログフィルタに対する変更は、新しい PE の起動時に有効になります。

PE マネージャーログフィルタに対する変更を有効にするには、SGD サーバーを再起動する必要があります。

注記

ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。この方法の詳細については、「PE ログフィルタのリセット」を参照してください。

7.4.5.1. 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/*/*"
注記

execpexpetpeppe、および cpe ログフィルタで pem/* フィルタを使用すると、そのプロトコルエンジンに関係する PE マネージャーメッセージが表示されます。

7.4.5.2. PE ログファイルの出力先

PE ログファイルのファイル名拡張子は、.log です。SGD により、このタイプのログ出力は読みやすく書式設定されます。

PE コンポーネントの名前とプロセス ID が含まれる PE ログファイル名。たとえば、プロセス ID 4512 で実行されている PE マネージャーメッセージは、pemanager4512.log です。

重要度が errorfatalerror、または warningerror のエラーメッセージは、error.log で終わる名前を持つ PE ログファイルに格納されます。たとえば、プロセス ID 2256 で実行されている文字型プロトコルエンジンのエラーメッセージは、cpe2256_error.log という名前のファイルに格納されます。このようなファイルは、error.log で終わる名前を持つログファイルだけを検索する tarantella query errlog コマンドによって使用されます。

PE ログフィルタ出力は自動的に、SGD ホスト上の /opt/tarantella/var/log ディレクトリ内のログファイルに格納されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。

7.4.5.3. PE ログ出力の表示

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 コマンドを実行することでいつでも設定を変更できます。

7.4.5.4. PE ログフィルタのリセット

ログフィルタを使用すると大量のデータが作成される可能性があるため、不要になったフィルタはリセットしてデフォルト設定に戻すことをお勧めします。

PE ログフィルタのデフォルト構成では、PE コンポーネントのすべてのサブコンポーネントに対して重要度 *error が設定されます。次の表に、各ログフィルタのデフォルト設定を示します。

プロトコルエンジン

ログフィルタのデフォルト設定

PE マネージャー

pem/*/*error

proxy/*/*error

実行プロトコルエンジン

execpe/*/*error

pem/*/*error

launchhelper/*/*error

X プロトコルエンジン

xpe/*/*error

pem/*/*error

文字型プロトコルエンジン

tpe/*/*error

pem/*/*error

印刷プロトコルエンジン

ppe/*/*error

pem/*/*error

チャネルプロトコルエンジン

cpe/*/*error

pem/*/*error

たとえば、X プロトコルエンジンのログフィルタをリセットするには、次のコマンドを使用します。

$ tarantella config edit \
--tarantella-config-xpeconfig-logfilter "xpe/*/*error" "pem/*/*error"

7.4.6. SGD Web サーバーのロギング

SGD Web サーバーのメッセージは次のログ内に記録されます。

  • Tomcat JSP テクノロジコンテナのログ

  • Apache Web サーバーのログ

7.4.6.1. Tomcat JSP テクノロジコンテナのログ

SGD Web サーバーの Tomcat JSP テクノロジコンテナコンポーネントのログメッセージは、SGD ホスト上の /opt/tarantella/webserver/tomcat/tomcat-version/logs ディレクトリ内の次のファイルに書き込まれます。

  • catalina.out – このログファイルがいっぱいになるか Tomcat JSP テクノロジコンテナが再起動されると、このファイルのローテーションが行われ、その内容が catalina.out.sav の末尾に追加されます。

  • localhost_log.date.txt – これは日次ログファイルであり、date はメッセージが記録された日付です。

これらのログファイルはテキストエディタを使って読むことができます。

Tomcat JSP テクノロジコンテナのログファイルを使えば、次の各項目に関する問題を診断できます。

  • Tomcat JSP テクノロジコンテナの起動と停止

  • AJP 1.3 Connector の起動

  • SGD Webtop Web アプリケーションのロード

  • Webtop JSP ソフトウェアの例外エラー

Tomcat JSP テクノロジコンテナのロギングプロパティーの構成は、/opt/tarantella/webserver/tomcat/tomcat-version/conf/logging.properties ファイル内で行います。Tomcat JSP テクノロジコンテナのロギングを構成する方法については、Tomcat ドキュメントを参照してください。

7.4.6.2. Apache Web サーバーのログ

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 ドキュメントを参照してください。

7.4.7. SGD Client のロギング

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 を使って、あるユーザーセッションのクライアントデバイス情報を表示できます。「ユーザーセッションリスト」テーブルでユーザーセッションを選択し、「詳細の表示」ボタンをクリックしてその詳細情報を表示します。