Documentation

既知の問題

REMOTE_HOST_HEADERSX_FORWARDED_FOR を使用する場合にセキュリティー上の問題が生じる可能性

Tower ノードを一部のプロキシーの背後に置くと、セキュリティーの問題が生じる可能性があります。この方法では、トラフィックは常にロードバランサーを経由するため、ロードバランサーを回避するトラフィックは X-Forwarded-For ヘッダーのスプーフィングの疑いがあります。「ag_proxy_support」を参照してください。

ホスト名を使って SAML メタデータにアクセスする際のサーバーエラー

Tower がホスト名のみを使ってアクセスされる場合 (例: https://my-little-tower)、/sso/metadata/saml/ から SAML メタデータを読み取ろうとすると sp_acs_url_invalid サーバーエラーが生成されます。

FQDN ではなくホスト名のみを使って Tower にアクセスする場合の SAML を使用する設定はサポートされていません。このアクセスを実行するとエラーが発生し、そのエラーは tower.log ファイルにキャプチャーされ、詳細なトレースバック情報と共にブラウザーに表示されます。

FIPS モードでの実行

本書の作成時点で、Tower はオペレーティングシステムが FIPS モードで動作するように設定されている場合の実行をサポートしていません。

単一ホストに対するホストの比較

単一ホストに対してホストの比較を実行する際、選択した日付に 1 つのみが実行される場合、Tower はいずれかの列にスキャンジョブの実行が見つからないというメッセージを表示する場合があります。

ライブイベントのステータスインジケーター

ライブイベントのステータスドットは、何かの問題が生じると Tower ダッシュボードの上部に赤またはオレンジのドットで表示されます。システムが健全な状態の場合にはドットは表示されません。システムが適切に機能しているように見える場合でも赤またはオレンジのライブイベントのステータスインジケーターが表示される場合、以下の提案が解決に役立つ可能性があります。

  • ブラウザーページのリフレッシュ/リロードを手動で試行する
  • Firefox および Safari は自己署名証明書を信頼する際に問題が発生すると報告されているため Web ブラウザーを変更してみる
  • DNS に一致する自己署名証明書を作成し、これを手動で信頼にインポートしてみる
  • 匿名またはプライベートのブラウズセッションを使用してみる
  • ブラウザープラグインを無効にしてサービスをブロックするものが何もなくなるようにする

ライブイベントのステータスドットは Tower インスタンスに関する問題のトラブルシューティングに使用され、socketio ログは問題点を指摘します。sosreport を実行してトラブルシューティングのヘルプを収集することができます。root でシステムから sosreport コマンドを実行し、診断 tar ファイルを自動生成し、収集した情報を基に追加のヘルプを得られるように Ansible のサポートチームに問い合わせます。

注釈

Ansible Tower 2.2.0 より、ライブイベントのステータスインジケーターは Tower が問題を検出する場合にのみ表示されます。これよりも前のリリースでは、健全なシステムの状態を示す緑のステータスドットが表示されていました。

VMWare 自己署名証明書

自己署名証明書を使用する vmware インスタンスをお持ちの場合、以下をクラウドグループの「Source Vars (ソース変数)」設定に追加する必要があります。

"source_vars": "---\nvalidate_certs: False",

ディスクの Celery Beat データベースが破損する

celery が正常にシャットダウンされない場合、/var/lib/awx/beat.db ファイルがディスクに残ります。

初期のコメントにトレースバックが確認される場合、/var/lib/awx/beat.db を手動で削除して Tower を再起動する必要があります。

Safari が web ソケットへの接続を確立できない

以下の接続エラーが Tower に表示されます。

_images/ki-tower-connect-error.png

このエラーは、Safari が自己署名証明書を使用する Web ソケットへの接続の確立を警告なしに拒否する結果として生じます。この問題を解決するには、Safari が最初にアクセスする web サイトを常に信頼するように設定する必要があります。

  1. 現在のブラウザーを閉じてサイトに再びアクセスします。Safari が web サイトの ID を確認できないことを示すエラーメッセージが表示されます。
  2. Show Certificate をクリックします。
  3. Always trust ... when connecting to ... チェックボックスにチェックを付けて Safari で接続を受け入れるようにします。

このチェックボックスにチェックを付けずに Continue をクリックすると、このエラーが残ります。

set_stats の Ansible モジュールが Ansible v2.2.2 まで利用できない

set_stats Ansible モジュールは Ansible 2.2.2 がリリースされるまで利用できません。このモジュールは、アーティファクトをワークフローのあるジョブから別のジョブに渡すために Tower で使用されます。回避策として、Ansible の開発ブランチでアーティファクトを使用できることに注意してください。

sudo/su がローカルの Playbook または local_actions を含む Playbook で予想通りに機能しない

完全にローカルの Playbook または一部の local_actions ケースを含む Playbook の使用時に sudo/su コマンドが機能しない例が報告されています。これは PRoot が有効にされていることによる可能性があります。ローカル Playbook または local_actions を含む Playbook で sudo/su コマンドを使用するには、PRoot を無効にする必要があります。ジョブの分離の有効化 トグルを オフ に設定して「Tower の設定」画面の ジョブ タブで PRoot を無効にすることができます。

_images/ki-job-isolation.png

保存 をクリックして変更を保存し、サービスを再起動します。

SSH カスタマイズを使用する際の問題

Ansible Tower の PRoot 機能は Playbook の実行時に表示し、使用する Playbook で利用可能な Tower ファイルシステム上のディレクトリーを制限します。Tower ユーザーのホームディレクトリーでカスタム SSH 設定を使用して SSH 動作のカスタマイズを試行する場合、このディレクトリーを PRoot で公開されるディレクトリーの一覧に追加する必要があります。

たとえば、/var/lib/awx/.ssh/config にカスタム SSH 設定を追加し、これを Tower ジョブで利用可能にするには、「Tower の設定」画面の ジョブ タブからアクセスする Job Execution Isolation Path (ジョブ実行の分離パス) フィールドでパスを指定することができます。

_images/ki-job-isolation_path.png

Ubuntu はバンドルインストールのサポート対象外

Ansible Tower 2.3.0 のバンドルインストーラーを使用している場合、Red Hat Enterprise Linux および CentOS のみが現時点でサポートされることに注意してください。Ubuntu のサポートはバンドルインストーラーに追加されていません。Ubuntu ユーザーは非バンドルインストーラーを引き続き使用することができます。

1 分以下のセッション制限により Tower インスタンスが中断

プロアクティブなセッション制限により、セッションがアイドルになるとユーザーがキックアウトされます。セッション制限を 1 分以下に設定すると Ansible Tower インスタンスが中断するのでこの設定を避けることを強く推奨します。

Ansible 2.0 戦略

Ansible 2.0 は ``strategy: free``などの戦略を導入しますが、これらの新規戦略の Ansible Tower のサポートは Tower version 2.4.0 の時点では利用できません。この Ansible 機能は今後のリリースまで Tower に追加されません。

Ansible Tower で``strategy: free`` の使用を試行する場合、ジョブは実行されますが、それらはジョブの詳細ページで正常に表示されません。

詳細については、次のリンクを参照してください: https://docs.ansible.com/ansible/playbooks_strategies.html

削除済みの OAuth 認証アカウントの再アクティブ化

ソーシャル認証を使用してログインするユーザーは削除されており、ユーザーは、システム管理者がユーザーが再度ログインできるように cleanup_deleted アクションを days=0 の設定で実行するまで再度ログインできず、再作成されることはありません。cleanup_deleted が実行されると、Tower は ansible-tower-service restart コマンドを使用して再起動される必要があります。cleanup_deleted アクションの実行前に削除されているアカウントはログインの試行時に「アカウントが非アクティブです」というメッセージを受信します。