Topics:
REMOTE_HOST_HEADERS
で X_FORWARDED_FOR
を使用する場合にセキュリティー上の問題が生じる可能性set_stats
の Ansible モジュールが Ansible v2.2.2 まで利用できないREMOTE_HOST_HEADERS
で X_FORWARDED_FOR
を使用する場合にセキュリティー上の問題が生じる可能性¶Tower ノードを一部のプロキシーの背後に置くと、セキュリティーの問題が生じる可能性があります。この方法では、トラフィックは常にロードバランサーを経由するため、ロードバランサーを回避するトラフィックは X-Forwarded-For
ヘッダーのスプーフィングの疑いがあります。「ag_proxy_support」を参照してください。
Tower がホスト名のみを使ってアクセスされる場合 (例: https://my-little-tower)、/sso/metadata/saml/ から SAML メタデータを読み取ろうとすると sp_acs_url_invalid
サーバーエラーが生成されます。
FQDN ではなくホスト名のみを使って Tower にアクセスする場合の SAML を使用する設定はサポートされていません。このアクセスを実行するとエラーが発生し、そのエラーは tower.log ファイルにキャプチャーされ、詳細なトレースバック情報と共にブラウザーに表示されます。
本書の作成時点で、Tower はオペレーティングシステムが FIPS モードで動作するように設定されている場合の実行をサポートしていません。
単一ホストに対してホストの比較を実行する際、選択した日付に 1 つのみが実行される場合、Tower はいずれかの列にスキャンジョブの実行が見つからないというメッセージを表示する場合があります。
ライブイベントのステータスドットは、何かの問題が生じると Tower ダッシュボードの上部に赤またはオレンジのドットで表示されます。システムが健全な状態の場合にはドットは表示されません。システムが適切に機能しているように見える場合でも赤またはオレンジのライブイベントのステータスインジケーターが表示される場合、以下の提案が解決に役立つ可能性があります。
ライブイベントのステータスドットは Tower インスタンスに関する問題のトラブルシューティングに使用され、socketio
ログは問題点を指摘します。sosreport
を実行してトラブルシューティングのヘルプを収集することができます。root でシステムから sosreport
コマンドを実行し、診断 tar ファイルを自動生成し、収集した情報を基に追加のヘルプを得られるように Ansible のサポートチームに問い合わせます。
注釈
Ansible Tower 2.2.0 より、ライブイベントのステータスインジケーターは Tower が問題を検出する場合にのみ表示されます。これよりも前のリリースでは、健全なシステムの状態を示す緑のステータスドットが表示されていました。
自己署名証明書を使用する vmware インスタンスをお持ちの場合、以下をクラウドグループの「Source Vars (ソース変数)」設定に追加する必要があります。
"source_vars": "---\nvalidate_certs: False",
celery が正常にシャットダウンされない場合、/var/lib/awx/beat.db
ファイルがディスクに残ります。
初期のコメントにトレースバックが確認される場合、/var/lib/awx/beat.db
を手動で削除して Tower を再起動する必要があります。
以下の接続エラーが Tower に表示されます。
このエラーは、Safari が自己署名証明書を使用する Web ソケットへの接続の確立を警告なしに拒否する結果として生じます。この問題を解決するには、Safari が最初にアクセスする web サイトを常に信頼するように設定する必要があります。
このチェックボックスにチェックを付けずに Continue をクリックすると、このエラーが残ります。
完全にローカルの Playbook または一部の local_actions ケースを含む Playbook の使用時に sudo
/su
コマンドが機能しない例が報告されています。これは PRoot が有効にされていることによる可能性があります。ローカル Playbook または local_actions を含む Playbook で sudo
/su
コマンドを使用するには、PRoot を無効にする必要があります。ジョブの分離の有効化 トグルを オフ に設定して「Tower の設定」画面の ジョブ タブで PRoot を無効にすることができます。
保存 をクリックして変更を保存し、サービスを再起動します。
Ansible Tower の PRoot 機能は Playbook の実行時に表示し、使用する Playbook で利用可能な Tower ファイルシステム上のディレクトリーを制限します。Tower ユーザーのホームディレクトリーでカスタム SSH 設定を使用して SSH 動作のカスタマイズを試行する場合、このディレクトリーを PRoot で公開されるディレクトリーの一覧に追加する必要があります。
たとえば、/var/lib/awx/.ssh/config
にカスタム SSH 設定を追加し、これを Tower ジョブで利用可能にするには、「Tower の設定」画面の ジョブ タブからアクセスする Job Execution Isolation Path (ジョブ実行の分離パス) フィールドでパスを指定することができます。
Ansible Tower 2.3.0 のバンドルインストーラーを使用している場合、Red Hat Enterprise Linux および CentOS のみが現時点でサポートされることに注意してください。Ubuntu のサポートはバンドルインストーラーに追加されていません。Ubuntu ユーザーは非バンドルインストーラーを引き続き使用することができます。
プロアクティブなセッション制限により、セッションがアイドルになるとユーザーがキックアウトされます。セッション制限を 1 分以下に設定すると Ansible Tower インスタンスが中断するのでこの設定を避けることを強く推奨します。
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
ソーシャル認証を使用してログインするユーザーは削除されており、ユーザーは、システム管理者がユーザーが再度ログインできるように cleanup_deleted
アクションを days=0
の設定で実行するまで再度ログインできず、再作成されることはありません。cleanup_deleted
が実行されると、Tower は ansible-tower-service restart
コマンドを使用して再起動される必要があります。cleanup_deleted
アクションの実行前に削除されているアカウントはログインの試行時に「アカウントが非アクティブです」というメッセージを受信します。