ランタイム問題のトラブルシューティング
正常性調査の失敗など、WebSphere Automation の通常操作中に問題が発生する場合があります。 最も一般的なランタイムの問題を修正する方法について説明します。
以下の問題によって、正常性調査が失敗する可能性があります。 調査に失敗した場合は、WebSphere Automation UI または REST API を使用して、調査のアーカイブ・ファイルをダウンロードします。 アーカイブを開き、analysis.logファイルにエラーがないか調べます。
- SHA2DRBG FIPS対応サーバーが WebSphere で登録に失敗する。JDKの修正パックをインストールした後、 SecureRandom でプロバイダーが利用できないというエラーメッセージが表示される。
- サーバーとの接続がないか、登録済みサーバーとの接続が失われました
- Instana アラートの調査が作成されない
- メモリー分析ランナー・ジョブに対するメモリー不足エラー
- ホスト example.com上のサーバーを識別できませんでした
- MyCustomRole役割に無効な権限can_view_websphere_inventoryが含まれています
- 「接続エラー: 読み取り操作がタイムアウトになりました (Connection error: read operation timed out)」エラー・メッセージでインストールが失敗する
- Red Hat® Enterprise Linux® 非 root ユーザーおよびグループ・モードの Installation Manager を使用した WebSphere Application Server Liberty でのフィックスのインストールが失敗する
- フィックスパックのインストール後のノード・エージェントの実行状況または同期エラー
- フィックスのインストールを続行できないというエラー・メッセージ
- フィックス・エラー・メッセージのインストール要求で問題が発生しました
- Windows サーバーの停止時のフィックスのインストール
- 修正のインストール中にContainerStatusUnknown でインストール-修正ポッドが停止しています
- AIX オペレーティング・システムを使用するターゲット・サーバーへの iFix のインストールが、エラー chmod で失敗します。フラグまたは 8 進数が正しくありません。
- メモリー・リークが検出された後に Webhook を呼び出すことができない
- エア・ギャップ・インストールで掲示板のインポート・ジョブが失敗する
- 「操作」>「アプリケーション・ランタイム」ページへのアクセス中にタイムアウトになりました
- FIPS 対応環境では、フィックスのインストールまたはメモリー・リーク調査が進行しない
- E メール通知が送信されない、wsa-secure-vulnerability-notifier ポッド・ログ内のサーバー・エラー・メッセージの ID を検証できない
- 運用手順書ログにファイル・アクセス許可エラーが含まれている
- Java SDK ランタイムの脆弱性を修正するための iFix オプションがない
- FIPS対応サーバーがJDKの修正パックをインストールすると、 WebSphere Automation への登録に失敗するSecureRandom SHA2DRBG for provider not availableエラー・メッセージ
- FIPS（連邦情報処理規格）に準拠するように構成された登録済みの WebSphere Application Server または WebSphere Application Server Liberty サーバーにJava SDKランタイム修正プログラムをインストールすると、以下のエラーが発生して失敗することがあります。
この問題を解決するには、以下の記事の手順に従って登録済みのサーバーを設定してください。Stack Dump = java.lang.RuntimeException: SecureRandom SHA2DRBG for provider <provider_name> not available - サーバーとの接続がないか、登録済みサーバーとの接続が失われました
- WebSphere Automation は、 WebSphere Application Server および WebSphere Application Server Liberty の使用量計量フィーチャーを使用して、サーバーを登録し、サーバーとの定期的な接続を維持します。 WebSphere Automation がサーバーに接続できない場合、または登録済みサーバーとの接続が 6 時間を超えて失われた場合、 WebSphere Automation は UI にビジュアル・インディケーターを表示して状況を認識します。 連絡が失われた原因が既知の許容可能な理由ではない場合は、以下の手順を実行して問題を診断し、解決してください。
- ターゲット・サーバーで使用量計量が正しく構成されていることを確認してください。
詳しくは、 セキュリティ監視の設定を参照してください。
- サーバーを再始動します。
サーバーが WebSphere Automationから削除された場合、または使用量計量フィーチャーが無効になっていた場合は、そのフィーチャーを有効にしてから、ターゲット・サーバーを再始動します。 このアクションにより、サーバーが再び WebSphere Automation に登録されます。 詳細については、「 サーバーの登録解除 」を参照してください。
- ネットワーク接続をチェックしてください。
使用量計量フィーチャーが適切に構成されているが、接続が確立されていない場合は、ターゲット・サーバー上のログで、サーバーと WebSphere Automationの間の通信をブロックする可能性があるネットワーク接続の問題が示されていないか確認してください。
- ターゲット・サーバーで使用量計量が正しく構成されていることを確認してください。
- Instana アラートの調査が作成されない
- この問題は、ホストが登録済みサーバーを持っていないことが原因である可能性があります。 調査マネージャーがホストの登録済みサーバーを検出しなかった場合は、以下のエラー・メッセージが調査マネージャーのログ・ファイルに書き込まれます。
Investigation cannot be started because no assets are registered with the example.com host. - メモリー分析ランナー・ジョブのメモリー不足エラー
(In version 1.3 or later) java.lang.OutOfMemoryError: Java heap space (In version 1.2) JVMDUMP039I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError"デフォルトでは、メモリー分析のランナー・ジョブのメモリー要求およびメモリー制限は 4 GB に設定されています。 これらの設定は、ランナー・ジョブがほとんどのヒープ・ダンプを分析するために十分です。 このエラー・メッセージが表示された場合は、アナライザーにヒープ・ダンプを分析するのに十分なメモリーがありませんでした。デフォルトのインスタンス名はmemoryAnalysisRunner設定のWebSphereHealthカスタム・リソースには、より多くのメモリーを割り振ることができます。 詳しくは、 WebSphereHealth カスタムリソースを参照。 あるいは、以下のコマンドを使用してWebSphereHealthインスタンスを編集することもできます。oc edit WebSphereHealth <instance-name> -n <namespace>wsa-healthです。 デフォルトの名前空間はwasautomationです。注: メモリーのデフォルトは 4Gi で、制限は 4Giです。 以下の例のように、メモリーをより大きな値(20Giなど)に増やすことができます。 メモリー要求とメモリー制限を同じ値に設定します。 Java VM は、制限によって指定されたメモリー量を使用して、最大ヒープ・サイズを計算します。 Kubernetes は、要求によって指定されたメモリー量をプロセスが取得できることのみを保証します。spec: analysisManager: Image: … memoryAnalysisRunner: resources: limits: cpu: '1' memory: 20Gi requests: cpu: 500m memory: 20Gi注: さらに多くのリソースをmemoryAnalysisRunnerに割り振る場合は、ワーカー・ノードが要求を処理できることを確認してください。- ホストexample.com上のサーバーを識別できませんでした
Failed to identify the server on host example.comこのエラーはいくつかの問題が原因で発生する可能性があります。 この問題を解決するには、以下のステップを試してください。- 管理対象サーバーのすべての前提条件が満たされていることを確認します。 詳細については、 マネージドサーバーの要件を参照してください。
- WebSphere Automation と管理対象サーバーの間の 接続のテスト。
- セットアップに関する問題のトラブルシューティング。
- MyCustomRole役割に無効な権限can_view_websphere_inventoryが含まれています
- バージョン1.1でカスタム役割に
can_view_websphere_inventory権限を組み込んだ場合、この権限はバージョン1.2で削除されました。 カスタム役割を修正するには、APIを使用する必要があります。- cpd UIから、APIキーを取得します。
cpdコンソールから、［ 順にクリックし、［ APIキー ］ボタンをクリックします。
- API呼び出しに使用する、ベアラー・トークンを取得します。
curl -k -X POST -H 'Content-Type: application/json' -d '{"username":"<user_name>","api_key":"<api_key>"}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/icp4d-api/v1/authorize - 役割のリストを取得します。 このリストは、拡張名と JSON メタデータを取得するために必要です。これらは、壊れたカスタム・ロールを変更する後続のステップで使用されます。
curl -X GET -k -v -H "Authorization: Bearer <bearer_token>" --header "Content-Type: application/json" --header "Accept: application/json" https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/roles例:
curl -X GET -k -v -H "Authorization: Bearer eyJhbGciOiJSUz..." --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"mycustomrole","description":"","permissions":[]}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/roles応答(切り捨て):
{"rows":[{"id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","key":"f60b72c3-ae7e-4860-8f98-649e316af6d2","doc":{"_id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","extension_id":"_ce_703424172539772929","extension_name":"f60b72c3-ae7e-4860-8f98-649e316af6d2","role_name":"mycustomrole","description":"","permissions":["can_view_websphere_inventory"]...],"messageCode":"success","message":"success"} can_view_websphere_inventory権限が含まれているカスタム役割ごとに、その権限を削除し、can_view_application_runtime_security権限に置き換えます。curl -X PUT -k -v -H "Authorization: Bearer <bearer_token>" --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"","description":"","permissions":['can_view_application_runtime_security']}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/role/<extension_name>例:
curl -X PUT -k -v -H "Authorization: Bearer eyJhbGciOiJSUz..." --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"mycustomrole","description":"","permissions":["can_view_application_runtime_security"]}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/role/f60b72c3-ae7e-4860-8f98-649e316af6d2応答(切り捨て):
{"id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","messageCode":"success","message":"success"}
- cpd UIから、APIキーを取得します。
- フィックスのインストールが失敗し、Connection error: read operation timed outエラー・メッセージ
runbook.log ファイルにこのエラーがあるためにフィックスのインストールが失敗した場合は、後で UI の 「フィックスのインストール」 をクリックして、フィックスのインストールを再開します。
- Linux または UNIX で Installation Manager をグループ・モードにしている非 root ユーザーに対して WebSphere Application Server Liberty でフィックスのインストールが失敗する
このエラーは、 WebSphere Automation がアクセスする InstallationManager.dat ファイルが、予期したとおりに非 root ユーザーのホーム・ディレクトリーに配置されていないために発生します。 この問題を回避するには、 InstallationManager.dat ファイルの実際の場所へのシンボリック・リンクを持つ InstallationManager.dat ファイルを非 root ユーザーのホーム・ディレクトリーに作成します。 以下の例を参照してください。
ln -s /<my_group_name>/InstallationManager_AppData/etc/.ibm/registry/InstallationManager.dat \ /home/<non-root-username>/etc/.ibm/registry/InstallationManager.dat- フィックスパックのインストール後にノード・エージェントの実行状況または同期化でエラーが発生する
- WebSphere Automation を使用して WebSphere Application Server Network Deployment のノードにフィックスパックをインストールした後に、以下のいずれかの問題が発生する場合があります。
- 管理コンソールでノードの実行状況が正しくない
- 管理コンソールでのノードの誤った同期化
- SystemOut.log ファイルに次のようなエラーがあります。
ADMD0026W: The version of the deployment manager (9.0.5.11) is earlier than that of this node (node1, 9.0.5.12).
これらの問題は、ノードのフィックスパック・バージョンがデプロイメント・マネージャー・ホストのバージョンより高いために発生します。 この問題を解決するには、デプロイメント・マネージャー・ホストをフィックスパック・バージョン以上のバージョンに手動で更新してください。
- Installation of the fix cannot proceedエラー・メッセージ
- もしInstallation of the fix cannot proceedエラー・メッセージが表示されます。以下のいずれかの問題が原因である可能性があります。
- WebSphere Automation と IBM Fix Centralの間に通信の問題が存在する可能性があります。
- WebSphere Automation が IBM Fix Centralで認証できないようにする構成上の問題が存在する可能性があります。
- WebSphere Automation が管理対象サーバーにフィックスをインストールするのを妨げるユーザー特権の問題が存在する可能性があります。
構成が正しいことを確認してください。 構成が正しく、通信の問題が疑われる場合は、約 1 時間後に修正の開始を再試行してください。
- Problem with request to install fixエラー・メッセージ
もしProblem with request to install fixエラー・メッセージが表示されるのは、特定のホストで複数のフィックスのインストールが開始されたためです。 特定のホストに一度にインストールできるフィックスは 1 つのみです。 現在のフィックスのインストール・プロセスが完了するまで待ってから、そのホストに別のフィックスをインストールしてください。
- Windows サーバーへのフィックスのインストールの停止
Windows サーバーへのフィックスのインストール・プロセスが不合理な時間停止した場合は、 Windows サーバーを再始動してから、フィックスのインストールを再開してください。
- 修正プログラムのインストール中に、ContainerStatusUnknown で Install-fix pod が停止する
- フィックスのインストールが停止して表示される可能性があります。Installing fixWebSphere Automation UI で、install-fix ポッドが
ContainerStatusUnknown状態のままになるようにします。 この状態にある間は、同じホストへの後続のインストールの試行は続行されず、次のエラー・メッセージが表示されます。WIORM0806E: 他のフィックスがホスト 'myhost.com' にインストールされています。 後でもう一度試してください。
ポッドの状況を確認するには、
ocget pod コマンドを実行します。ContainerStatusUnknown状態を探します。oc get pod | grep install-fix install-fix-f6054b58-f20d-4351-8c44-7c1efd93f2d5-9m89j 0/1 ContainerStatusUnknown 1 48mこの問題を回避するには、
in-progress状況を決して経過しない停止状態のインストール済み環境を削除してから、関連するインストール修正ジョブを削除する必要があります。 - AIX オペレーティング・システムを使用したターゲット・サーバーへの iFix のインストールがエラーで失敗するchmod: A flag or octal number is not correct
- このエラーは、接続ユーザーと
become_userの両方が特権を持たない場合に、 AIX オペレーティング・システムで Ansible を使用することに関連しています。 この問題が再発しないようにするには、以下の手順を実行します。--from-literal=ansible_pipelining=trueをシークレットに追加します。- すべての管理対象ホストの /etc/sudoers ファイルで
requirettyを無効にします。これを行うには、以下の例に示すように、Defaults requiretty行をコメント化します。#Defaults requiretty
- メモリー・リークが検出された後に Webhook を起動できない
- Instana アラート・スキーマに対する予期しない更新が原因で、この問題が発生する可能性があります。 WebSphere Automation は、JSON スキーマを使用して、Instana から送信された JSON を検証します。 WebSphere Automation が使用するスキーマは、
wsa-schema-instana-alerts構成マップで設定されます。 環境変数$WSA_INSTANCE_NAMESPACEが WebSphere Automation インスタンス名前空間に設定されていることを確認します。- デフォルトの ConfigMap から、
instana-alerts-custom.jsonという名前のローカル・ファイルとしてデフォルトの Instana アラート・スキーマを取得します。oc get cm wsa-schema-instana-alerts -n $WSA_INSTANCE_NAMESPACE -o "jsonpath={.data['instanaAlerts\.json']}" > instana-alerts-custom.json instana-alerts-custom.jsonJSON ファイルに必要な変更を加えます。- カスタム ConfigMapを作成します。
oc create cm wsa-schema-instana-alerts-custom -n $WSA_INSTANCE_NAMESPACE --from-file=instanaAlerts.json=instana-alerts-custom.json
- デフォルトの ConfigMap から、
- エア・ギャップ・インストールで掲示板のインポート・ジョブが失敗する
エア・ギャップ・インストールでは、
wsa-secure-bulletins-importポッドが完了できない場合があります。 例えば、以下のコマンドを実行するとします。oc get pods | grep importエラーのある出力が表示される場合があります。
wsa-secure-bulletins-import-1.6.0-8526l 0/1 エラー 0 2d15h wsa-secure-bulletins-import-1.6.0-b7jld 0/1 エラー 0 2d15h wsa-secure-bulletins-import-1.6.0-c4cxf 0/1 エラー 0 2d15h wsa-secure-bulletins-import-1.6.0-dsmdg 0/1 エラー 0 2d15h wsa-secure-bulletins-import-1.6.0-fgj7p 0/1 エラー 0 2d21h wsa-secure-bulletins-import-1.6.0-kw9qm 0/1 エラー 0 2d15h wsa-secure-bulletins-import-1.6.0-t5sgl 0/1 エラー 0 2d15h
その場合は、掲示板のインポート・ジョブを削除します。
oc delete job wsa-secure-bulletins-import-1.6.0新しい掲示板のインポート・ジョブが作成されます。
- ページにアクセスしてタイムアウトを超えました
- WebSphereSecure UI が Red Hat OpenShift でプロビジョニングされた証明書を使用するときに Platform UI インスタンスに接続できない場合、この問題が発生します。 アプリケーションが通信に失敗すると、ブラウザーがタイムアウトになり、以下のエラーが表示されます。
timeout of 20000ms exceededこの問題を解決するには、WebSphereSecure UI 配置（
<instance-name>-secure-ui）を削除してアプリケーションを再起動します。例えば、 WebSphere Automation インスタンス名が
wsaの場合は、wsa-secure-uiを削除する必要があります。oc delete deployment deployment_name コマンドを使用して、関連するデプロイメントを削除します。
oc delete deployment <instance-name>-secure-ui -n <namespace> - FIPS 対応環境で、フィックスのインストールまたはメモリー・リークの調査が進行しない
- WebSphere Automationの FIPS 対応インストール済み環境の非 FIPS システムで生成された SSH 鍵ペアを使用する場合、フィックスの適用やメモリー・リーク調査が進行しない可能性があります。 ポッド・ログは、以下の行で停止する可能性があります。
[07/28/23 18:27:00:516 UTC] 1 com.ibm.ws.automation.core.runbook.runner.RunbookRunnerCLI INFO start Request received to execute runbook: install-fix against server: server1.example.com (correlationId: 65301e97-5754-4001-afbe-0c669d6774ff) [07/28/23 18:27:00:607 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook Here is the standard output of the command: [07/28/23 18:27:00:613 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook was: [07/28/23 18:27:00:613 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook hosts: [07/28/23 18:27:00:613 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook server1.example.com: [07/28/23 18:27:00:613 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook ansible_user: root [07/28/23 18:27:00:625 UTC] 1 com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook Agent pid 41この問題は、非 FIPS システム上の
ssh-keygenコマンドが MD5 ダイジェスト・アルゴリズムを使用して鍵を生成するために発生します。 FIPS 対応システムでは、 MD5 ダイジェスト・アルゴリズムは無効になっています。 パスフレーズのない SSH 鍵ペアは影響を受けません。FIPS 対応クラスターで WebSphere Automation を実行する場合は、以下のいずれかのオプションを選択して、FIPS 対応システムでパスフレーズで保護された SSH 鍵ペアを使用します。
- FIPS 対応システムで、新しいパスフレーズで保護された SSH 鍵ペアを生成します。
- 既存の秘密鍵を FIPS 互換フォーマットに変換します。
$ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT FILENAME> -out <OUTPUT FILENAME> Enter pass phrase for id_rsa: <PASSPHRASE OF EXISTING KEY> Enter Encryption Password: <PASSPHRASE FOR NEW KEY> Verifying - Enter Encryption Password: <PASSPHRASE FOR NEW KEY>
- E メール通知が送信されず、
wsa-secure-vulnerability-notifierポッド・ログにCan't verify identity of serverエラー・メッセージが記録される WebSphere Automation 1.7以降では、以前のバージョンよりも安全な Javamail サービスが使用され、TLS 接続を確立するときにサーバー ID が強制されます。 証明書がメール・サーバーのホスト名と一致しない場合、セキュア接続を確立できず、E メールは送信されません。
E メールの送信時にホスト名の検証を無効にするには、 「通知」 ページで mail.smtps.ssl.checkserveridentity プロパティーを
falseに設定します。- 「通知の管理」 特権を持つユーザーとして WebSphere Automation にログインします。
- クリックし、 通知ページを開きます。
- 「通知」 ページの 「E メール・サーバー」で、 「サーバーの構成」をクリックします。
- 「追加フィールドの追加」の下の 「追加」 ボタンをクリックします。
- mail.smtps.ssl.checkserveridentity パラメーターを追加し、その値を
falseに設定します。 - 保存 をクリックします。
- 運用手順書ログにファイル・アクセス許可エラーが含まれている
WebSphere Automation プレイブックでは、 ansible_user 接続変数に定義されているユーザー・プロファイルに、以下の WebSphere Application Server 従来型ファイルとその親ディレクトリーに対する読み取り権限が必要です。
app_server_root/properties/profileRegistry.xml app_server_root/properties/version/installed.xmlansible_user 接続変数に定義されているプロファイルがファイルを読み取れない場合、運用手順書ログに以下のようなエラーが表示されることがあります。
ValueError: File not found or no permissions to access app_server_root/properties/version/installed.xmlまたは
Permission denied: 'app_server_root/properties/profileRegistry.xml'ファイルに対する読み取りアクセス権を付与するには、オペレーティング・システム・ツールを使用してファイルのアクセス権を変更します。 例:
chmod +r /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml chmod +r /opt/IBM/WebSphere/AppServer/properties chmod +r /opt/IBM/WebSphere/AppServer/properties/version/installed.xml chmod +r /opt/IBM/WebSphere/AppServer/properties/version役に立つかもしれない追加情報は、 WebSphere Application Server ドキュメントの「 Granting write permission for profile-related tasks 」にあります。 特にステップ 8 を参照し、リンクされた資料のユース・ケースが異なることに留意してください。これらの指示に明示的に従わないでください。
- Java SDK ランタイムの脆弱性を修正するための iFix オプションがない
- 「修正の準備」 ダイアログでは、Java SDK ランタイムの脆弱性を修正するためのオプションとして、暫定修正 (iFixes) は表示されません。 「グローバル・オプションの選択」 ページで 「フィックス・タイプ」 として 「フィックスパック」 を選択してから、 「フィックスの選択」 ページでインストールするフィックスパックを選択する必要があります。