この付録では、ACSLS における問題のトラブルシューティングのためのツール、ヒント、および手法についてまとめています。トラブルシューティングリソースの範囲には、ログ、鍵監視ポイント、診断プローブが含まれます。
ACSLS イベントログは、ライブラリの操作に問題が発生した場合に、有用な情報が得られる最初の場所です。このログには、ライブラリイベント、ステータスの変更、およびエラーに関する情報が含まれます。ACSLS 内のすべてのサブコンポーネントは、イベントロガーと呼ばれるプロセスにメッセージを送信することによって、acsss_event.log にイベントを報告します。標準のイベントログは、ACSLS がインストールされるときに自動的に作成され、$ACS_HOME/log/acsss_event.log のファイルに含まれます。ここで、$ACS_HOME は通常、/export/home/ACSSS/ です。
記録されるイベントは次のとおりです。
重大なイベント
重大なイベントとは、ライブラリの管理に役立つ通常のイベントです。たとえば、イベントは、監査が開始または終了したとき、デバイスが状態を変更したとき、CAP が開かれたり閉じられたりしたときに記録されます。
ライブラリのエラー
ライブラリのエラーは、ハードウェアおよびソフトウェアの致命的なエラーと致命的でないエラーの両方が記録されるイベントです。たとえば、LSM の障害、カートリッジの問題、データベースエラー、プロセスの障害、ライブラリ通信障害などがあります。
イベントログ内の各メッセージには、タイムスタンプ、メッセージを報告しているコンポーネントの名前、およびイベントの説明が含まれます。各メッセージの詳細な説明については、『ACSLS メッセージ』のマニュアルを参照してください。
ACSLS コンソールのウィンドウには、イベントログの実行中の最後の部分が表示されます。どのシェルウィンドウからでも同様の表示を生成できます。
ユーザー acsss として、次のコマンドを実行します。
acs_tail $ACS_HOME/log/acsss_event.log
イベントログ全体を表示するには、ログ内を移動したり、特定のエラーを検索したり、特定のイベントシーケンスをたどったりできる、vi などのテキストエディタを使用します。
ACSLS は、acsss_event.log にメッセージを送信し続けます。
このファイルがしきい値サイズ (デフォルトで 500K バイト) に達すると、ファイルは event0.log の名前に変更され、ログディレクトリに保存されます。そのあと、acsss_event.log は新しいファイルとして存続します。
acsss_event.log が再度しきい値サイズに達すると、event0.log の名前が event1.log に変更され、acsss_event.log の名前が event0.log に変更されます。
このプロセスは、ログファイルが保持するように構成されている数に達するまで続行します。
デフォルトでは、9 つのイベントログファイルがログディレクトリ内に保持されます。それ以降にしきい値に達するごとに、もっとも古いファイルから削除され、残りのすべてのファイルの名前が順次変更されます。
acsss_config、オプション 2 を使用して、acsss_event.log の最大サイズと保持するログファイル数を構成できます。CSI チューニング変数の設定を参照してください。
診断ツール、greplog を使用すると、あらゆるイベントログファイルに対してキーワード検索を実行できます。greplog は、UNIX の grep ユーティリティーと使用法が非常によく似ており、指定されたキーワード式に関連した完全なログメッセージを返します。これを使用して、メッセージの日付とタイムスタンプ、メッセージ番号、およびその式を含んでいるすべてのメッセージに関連する関数テキストを表示できます。
log/acsss_event.log には、ACSLS 実行プロセスのあらゆる側面に関するすべてのメッセージが含まれます。ただし、バックアップおよび復元ユーティリティーやインストールユーティリティーなど、外部ユーティリティーに関するステータス情報を含んだ追加ファイルが、ログディレクトリにあります。
acsss.pid - 現在実行している acsss_daemon のプロセス ID が格納されます。
acsss_config.log - 各ライブラリ構成のサマリーが含まれます。
acsss_config_event.log - acsss_config ルーチンによって書き込まれたイベントメッセージが含まれます。
bdb_event.log - データベースバックアップユーティリティー、bdb.acsss によって書き込まれたイベントメッセージが含まれます。
cron_event.log - cron ユーティリティーによって書き込まれたメッセージが含まれます。cron スケジュールを表示するには、crontab -l コマンドを実行します。
acsls_start.log - acsls サービスが関与する起動または停止メッセージが含まれます。
di_trace.log - データベースのインタフェースに関するトレース情報が含まれます。
ejectingLogs - 過去 10 日間の ejecting.sh 操作からのサマリー情報が含まれるディレクトリ。
install.log - インストールスクリプト、install.sh を実行している場合に書き込まれたイベントメッセージが含まれます。
ipc_trace.log - ACSLS プロセス間通信に関するトレース情報が含まれます。
rdb_event.log - データベース復元ユーティリティー、rdb.acsss によって書き込まれたイベントメッセージが含まれます。
timed_bkup.sh.log - 自動データベースバックアップユーティリティーに関連するイベントメッセージが含まれます。
システム上で有効にしている特定のトレースに応じて、その他のトレースログがログディレクトリに置かれている場合があります。このログには次のものがあります。
acsss_stats.log - ボリューム統計トレースは、acsss_config によって有効になります。
acsss_trace.log - クライアントとサーバー間のトレースは、ソフトウェアサポート担当者のリクエストで有効になります。
acslh.log - ホストと LMU 間のトレースは、ソフトウェアサポート担当者のリクエストで有効になります。
scsilh.log、mchangerX.log、scsipkt.log - これらはすべて、SCSI 接続ライブラリへの SCSI 通信のトレースを含み、ソフトウェアサポートのリクエストで有効になります。
ソフトウェアサポートのリクエストで有効になるトレースログは、非常に急速に増大する可能性があります。いっぱいのディスクの問題を軽減するために、これらのログをモニターおよび管理する必要があります。
自動ログ管理およびアーカイブサービスを実行するユーティリティー monitor.sh が用意されています。その構文は次のとおりです。
monitor.sh <ログの名前>
特定のログをモニタリングするためにこのユーティリティーが有効になっている場合、1M バイトのサイズ (デフォルト) までログを増大でき、そのあと、gzip を使用してログを圧縮し、タイムスタンプ付きの名前の圧縮ログファイルを ACSSS/log/log_archives サブディレクトリに配置します。トレースが有効なままであれば、この操作は続行されます。
ACSLS GUI や論理ライブラリソフトウェアコンポーネントなど、ACSLS 内の Java コンポーネントによって多数のログが管理されています。これらのログは $ACS_HOME/log/sslm ディレクトリにあります。
WebLogic のインストール手順は weblogic.log に記録されます。WebLogic および ACSLS GUI の操作は、AcslsDomain.log と AdminServer.log に記録されます。
Web ベースの GUI でのユーザーアクティビティーの監査トレールは、guiAccess.log にあります。
Java コンポーネントとレガシー ACSLS コンポーネント間のトランザクションは surrogate_trace.0.log に記録されます。
Java クライアントコンポーネントと ACSLS サーバー間の IPC パケットは acslm_ipc_trace.0.log 内でトレースされます。
ACSLS GUI で発生したエラーは、gui_trace.0.log に記録されます。
SMCE と SCSI (ファイバ) クライアント間の低レベルの通信は、smce_trace.0.log に記録されます。
これらのログは $ACS_HOME/log/sslm ディレクトリにあります。
acsss_event.log を調べます。
acsls_start.log を調べます。
問題を説明するメッセージがないか、acsss_event.log の末尾を調べます。
メッセージの説明と、これらを解決するために行える対処法については、『ACSLS メッセージ』ガイドを参照してください。
acsss l-status を使用して、ACSLS サービスのステータスを表示します。
acsss l-status を使用して、ACSLS サービスのステータスサマリーを表示します。サービスごとに、logfile エントリは、ACSLS が起動できなかった状況について説明した詳細メッセージを含む可能性のあるログデータを示します。
ACSLS が起動中にタイムアウトします
Solaris では、構成に基づいて計算された ACSLS の起動時タイムアウト期間を表示するために、acsss timeout を使用します。
ACSLS には、ライブラリへの良好な物理的接続を検証するユーティリティーが用意されています。どのツールを選択するかは、アクティビティーのコンテキストによってもっとも適切に決まります。
このユーティリティーは、StorageTek ACSLS に対して構成されている各ライブラリへの接続をテストします。また、これはもっとも簡単に使用でき、もっとも便利です。このテストは目立たず、通常のライブラリ操作に影響を与えません。testports は StorageTek ACSLS データベースを使用してライブラリのポート名とライブラリタイプを判別するため、 testports が機能するように、ライブラリはすでに StorageTek ACSLS に対して構成されている必要があります。
TCP/IP ライブラリの場合、testports は、接続を検証し、ライブラリがオンラインになっており StorageTek ACSLS で使用されているかどうかを検証します。
SCSI およびシリアル接続したライブラリの場合、「'acs」および「port」は、testports がテスト接続を開くために、オフラインになっている必要があります。
このユーティリティーを実行するためのコマンドの構文は次のとおりです。
testports
ライブラリの互換性レベルまたはマイクロコードレベルを表示します。
このユーティリティーは、ネットワーク接続ライブラリに TCP/IP パケットを送信します。
ライブラリの接続をテストするには、コマンド行で、ライブラリのホスト名または IP アドレスを含めます。
testlmutcp <ip_address> または
testlmutcp <hostname>
ライブラリが ACSLS に対してオンラインになっているときに接続をテストするには、50002 から 50016 の未使用のソケット番号を指定します。次に例を示します。
testlmutcp <ip_address>:50002
正常な応答には、接続されたライブラリの互換性レベルが含まれます。
このユーティリティーは、ACSLS とレガシー StorageTek シリアル接続ライブラリ間の接続のテストに使用できます。このユーティリティーを実行するには、シリアルポートデバイスノードへの devlink パスを送信します。
testlmu /dev/term/0
testlmu がシリアル接続を開けるように、ACSLS に対してライブラリをオフラインにする必要があります。
このユーティリティーを使用すると、ライブラリが ACSLS に対してオンラインになっているときに、ACSLS とシリアル接続ライブラリ間の通信を検証できます。正常な応答には、ライブラリの互換性レベルが含まれます。
このユーティリティーは、ACSLS サーバーと SCSI またはファイバ接続ライブラリ間の接続を実行します。このユーティリティーを実行するには、mchanger デバイスへの devlink パスを指定します。その構文は次のとおりです。
probescsi.sh /dev/mchangerX
ここで、X は、テストされるライブラリの特定の mchanger インスタンスです。
probescsi が SCSI 接続を開けるように、ライブラリを ACSLS に対してオフラインにする必要があります。正常な応答には、接続されたライブラリのマイクロコードレベルが含まれます。
クライアントアプリケーションは、RPC (リモートプロシージャーコール) プロトコルを使用して TCP/IP 上で ACSLS と通信します。クライアントシステムが ACSLS と通信できない場合は、rpcinfo を使用して、ACSLS がクライアントマシンから到達可能かどうかをテストできます。
ACSLS サーバーから、ACSLS が実行していることを検証します。
psacs
ACSLS サーバーから、RPC デーモンが実行していることを検証します。
ps -ef | grep rpc
ACSLS サーバーから、TCP および IDP に対してプログラム番号 300031 が登録されていることを検証します。
rpcinfo | grep 300031
このプログラム番号は、ACSLS が実行しており、ACSLS が RPC に登録していることを確認します。
クライアントマシンから、またはネットワーク上のすべての UNIX マシンから、rpcinfo を使用して、ACSLS サーバー上のプログラム番号 300031 とパケットを交換します。
プログラム番号とともに ACSLS サーバーの IP アドレスを指定します。
rpcinfo -t <ip address> 300031
通信交換が成功した場合、rpcinfo ユーティリティーは、次のメッセージを表示します。
program 300031 version 1 ready and waiting
program 300031 version 2 ready and waiting
これは、ACSLS がネットワーク全体のクライアント接続に使用できることを確認します。
ブリッジドライブを介して接続されるファイバ接続ライブラリ内の CAP が、別の ACSLS インスタンスがライブラリの管理を引き継ぐときに、ロックされる場合があります。詳細とこの問題の解決方法は、SL150 の付録で 取り出し中に開かない CAP (メールスロット)を参照してください。
Oracle Support では、サービスコールの一部として診断ログのセット全体および分析用のほかの診断情報を送信するよう依頼することがあります。このすべてのデータは単一のコマンドで収集できます。
get_diags
このユーティリティーですべての情報が収集されると、データを電子メールで送信するか、手動転送を使用可能にするかを尋ねるプロンプトが表示されます。
データを直接 ACSLS マシンから電子メールで送信することにした場合は、ACSLS マシンとインターネット間で電子メール通信が可能であることを確認します。企業によっては、ターゲットマシンとの電子メールの送受信がファイアウォールによってブロックされることがあります。この場合は、情報を社内の自分宛に電子メール送信してから、Oracle Support に診断データを転送してください。
または、情報を手動で転送することも選択できます。get_diags ユーティリティーで、転送待機中の tar パッケージが見つかる場所がアドバイスされます。通常、診断データ用のステージング領域は /export/backup/diag/acsss にあります。
SELinux は、Oracle Linux ではデフォルトで有効になっています。SELinux は、標準 Unix レベルのアクセス制御以上に、ユーザーロールおよびイミディエイトコンテキストドメインに応じて、システムリソースへのアクセスを強制します。SELinux の強制が有効になっている場合、独自の PostgreSQL データベースにアクセスする ACSLS の機能は、このようなアクセスに対してロールとコンテキストを確立する特別なポリシーがなければ妨げられます。
ACSLS をインストールすると、3 つの SELinux ポリシーモジュール (allowPostgr、acsdb、acsdb1) がカーネルにロードされます。これらのモジュールでは、SELinux の強制がアクティブなときに独自のデータベースおよびその他のシステムリソースにアクセスするために ACSLS で必要となる定義および強制例外が提供されます。これらのモジュールがインストールされていると、SELinux の強制を無効にすることなく、通常の ACSLS 操作 (bdb.acsss、rdb.acsss、db_export.sh、db_import.sh などのデータベース操作を含む) を実行できます。
迅速なソフトウェアアップグレードのために、ACSLS によってロードされた SELinux ポリシーモジュールは、ACSLS パッケージをアンインストールするときに自動的には削除されません。それらを手動で削除するには、ACSLS モジュールのリストを取得します。
# semodule -l | grep acsdb
# semodule -l | grep allowPostgr
モジュールごとに、次の方法でモジュールを削除します。
# semodule -r <module name>
ACSLS のインストール後、従来のファイルアクセス許可設定が有効であると思われるのに、システムから「Permission denied」と返されるようなアクセス関連の問題が発生した場合、そのアクセス拒否の原因が SELinux にある可能性があります。
SELinux の強制が有効になっているかどうかを確認するには、sestatus コマンドを実行します。
# sestatus SELinux status: enabled Current mode: enforcing
setenforce コマンドを使用して一時的に SELinux の強制を無効にできます。
# setenforce Permissive
SELinux の強制が許可モードであれば、障害の発生したリソースへのアクセスを復元できるかどうかを確認できます。許可モードにあるが強制モードにはない承認されたユーザーが、必要なリソースを利用できる場合、SELinux ポリシーの更新が必要であることを示しています。
SELinux のセキュリティーを永続的に (ブートにわたって) に無効にするには:
/etc/selinux/config のファイルを編集します
SELINUX=enforcing を SELINUX=permissive に変更します
SELinux の強制をふたたび有効にするには、root が sysadm_r ロールを持っている必要があります。
# newrole -r sysadm_r # setenforce enforcing
SELinux が明らかに制限の原因であったことを検証し終えたら、SELinux の監査ログを調べることによって、必要なリソースへのアクセスを許可しなかった実際のルールを確認できます。
# vi /var/log/audit/audit.log
audit.log は、SE の強制が成功または失敗したそれぞれのアクセス試行に関するサマリーを提供します。失敗したイベントを探す必要があります。ACSLS の場合、特にユーザーの acsss および acsdb に関連したイベントを調べます。
どのファイルまたはディレクトリに関連付けられた SELinux コンテキスト属性でも表示できます。
# ls -Z <file name>
secon のコマンドを使用して、所定のプロセスのコンテキスト属性または現在のシェルのコンテキスト属性を表示できます。chcon コマンドを使用して、ファイルまたはディレクトリのコンテキスト属性を変更できます。これらの操作については、マニュアルページを参照してください。
audit.log で見つかった失敗した操作に応じてポリシーモジュールを作成できます。
# cd /var/log/audit # audit2allow -a -M <ModuleName>
これは、SELinux によって記録された障害を評価し、ポリシーモジュールファイル <ModuleName>.pp を作成します。このファイルは、ブロックされていた操作を許可するために、Linux カーネルにロードできます。
# semodule -i <ModuleName>.pp
audit2allow は、audit.log で識別されるすべての制限を許可するポリシーを作成するため、audit.log には特に許可する操作しか含まれていないように確認することをお勧めします。元の audit.log を保存して、新しいログを作成できます。
# mv audit.log audit1.log # touch audit.log
ポリシーモジュールを作成する前に、取得する操作を続行します。
SELinux に関する詳細は、マニュアルページを参照してください。
# man selinux
checkGui.sh ユーティリティーは一般的な要素を確認して、GUI が動作しているかどうかを評価します。GUI が動作していない場合、このユーティリティーは、問題の可能性の高い原因をユーザーに示すことができます。
このユーティリティーは次の点を確認します。
Weblogic がシステム上で有効になっていますか。
疑似プロセスまたは古いプロセスが Weblogic 操作を妨げている可能性はありますか。
SlimGUI アプリケーションが正常に配備されていますか。
Weblogic および GUI は、localhost に送信される HTTP リクエストに応答できますか。
Weblogic は、ホストのインターネットアドレスに送信される HTTP リクエストに応答できますか。
ファイアウォールサービスがサーバー上で有効になっていますか。その場合、Weblogic ポート 7001 および 7002 への受信リクエストを受け入れるポリシーはありますか。
Linux システムでは、iptables と呼ばれるファイアウォールがデフォルトで有効になっている場合があります。iptables を完全に無効にすることも、ポート 7001 および 7002 への受信トラフィックを受け入れるポリシーを追加することもできます。
これらのポートを (root として) 有効にするには、ファイル /etc/sysconfig/iptables を編集します。次の 2 行を追加します。
-A INPUT -p tco --dport 7001 -j ACCEPT -A INPUT -p tco --dport 7002 -j ACCEPT
これらのルールは絶対に、調べられる前に受信パケットを照合する別のルールのあとに挿入しないようにしてください。たとえば、REJECT all を行うルールのあとの iptables チェーンの末尾に付加しないでください。
iptables コマンドを使用してこれらのルールを追加する場合:
テーブルを一覧表示 (iptables -L) または出力 (iptables -S) します。
ルールを追加します。
前のルールによって新しいルールが入力を照合できなくなる場合があるため、チェーンの末尾にルールを追加するだけでは (iptables –A) 目的の結果が生成されない可能性があります。
たとえば、rulenum によってルールを挿入します (iptables -I)。
変更後、テーブルを一覧表示 (iptables -L) または出力 (iptables -S) して、既存のルールによってポート 7001 および 7002 の新しいルールが調べられないようになっていないことを確認します。
これにより、新しいルールは受信パケットを照合できるようになります。
checkGui.sh ユーティリティーは、ポート 7001 および 7002 で入力を受け入れるルールが存在するかどうかを確認します。これは、これらのルールが右側の iptables チェーン内にあることも、新しいルールが実際に処理されることも検証しません。言い換えれば、checkGui.sh は、新しいルールの検査を妨げる前のルールが存在しないことを検証しません。
iptables を再起動します。
service iptables restart
Solaris での同等のサービスは ipfilter であり、通常はデフォルトで有効になっていません。
次の表では、GUI のトラブルシューティングのヒントについて説明します。
| 問題 |
解決方法 |
|---|---|
|
ブラウザに https://<hostname> と入力しましたが、応答ページには「Unable to connect」と表示されます。 |
正しい URL は https://hostname.domain:7002/SlimGUI/faces/Slim.jsp です |
|
ACSLS GUI ページが不完全です。一部のフレームが不完全であったり、セクション全体が見つかりません。 |
ブラウザのリフレッシュボタンをクリックします。 |
|
有効なことがわかっているユーザー ID とパスワードが、Java WebLogic で拒否されます。ログインできません |
ローカルの ACSLS 管理者に問い合わせてください。管理者である場合、userAdmin.sh ユーティリティーを使用して、ユーザーの一覧表示、ユーザーの追加、またはユーザーパスワードの変更を行なってください。 まだユーザーにログインの問題がある場合は、システムに十分なメモリーがあるかを確認してから、userAdmin.sh のオプション 5 を使用して ACSLS GUI を再起動してください。または、svcadm disable weblogic および svcadm enable weblogic を使用して Weblogic を再起動できます。 |
|
Java エラースタックトレースが、GUI の 1 つ以上のウィンドウに表示されます。 |
ブラウザのリフレッシュボタンを押します。 問題が解決しない場合は、 サービスが実行していない場合は、 ACSLS サービスが実行している場合、userAdmin.sh を使用して GUI を再起動します。または、svcadm disable weblogic および svcadm enable weblogic を使用して Weblogic を再起動できます。 システムに |
|
インデックスツリーフレームで「論理ライブラリ」の選択肢が見つかりません。 |
最初に論理ライブラリを作成する必要があります。「Configuration and Administration」 -> 「Logical Library Configuration」 -> 「Create Logical Library」を選択します。 |
|
「Tape Library Operations」または「Tape Libraries & Drives」の下の「Volumes」ページにボリュームが一覧表示されていません。 |
これは、初期監査がライブラリに対して行われていないことを示します。「Tape Library Operations」 -> 「Audit」を選択します |
|
「Logical Libraries」の下の「Volumes」ページにボリュームが一覧表示されていません。 |
これは、ボリュームがボリュームライブラリにまだ割り当てられていないことを示しています。「Logical Library Configuration」 -> 「Assign Volumes」を選択します。 |
|
GUI の応答時間が遅くなっています。 |
GUI マストヘッドの「Preferences」ボタンの下にある「Alert Update Interval」を増やします。 |
|
GUI ユーザーの追加、GUI ユーザーのパスワードの変更、または |
userAdmin.shを参照してください。 このユーティリティーを使用すると、ユーザーの追加とユーザーのパスワードの変更を行え、 |
|
ブラウザがセキュリティー証明書を必要としています。 |
HTTPS 用の自己割り当てデジタル証明書の構成を参照してください。 |