Topics:
REMOTE_HOST_HEADERS
で X_FORWARDED_FOR
を使用する場合にセキュリティー上の問題が生じる可能性分離されたジョブを開始した後にそれを管理するインスタンスを強制終了すると、Tower はジョブのステータスを判別できず、手作業による設定が必要になります。この状況についての詳細は、Red Hat カスタマーポータル (https://access.redhat.com/) 経由で Ansible までお問い合わせください。
REMOTE_HOST_HEADERS
で X_FORWARDED_FOR
を使用する場合にセキュリティー上の問題が生じる可能性¶Tower ノードを一部のプロキシーの背後に置くと、セキュリティーの問題が生じる可能性があります。この方法ではトラフィックは常にロードバランサーを経由することが想定されるため、ロードバランサーを回避するトラフィックには X-Forwarded-For
ヘッダーのスプーフィングの疑いがあります。 プロキシーのサポート を参照してください。
Tower がホスト名のみを使ってアクセスされる場合 (例: https://my-little-tower)、/sso/metadata/saml/ から SAML メタデータを読み取ろうとすると sp_acs_url_invalid
サーバーエラーが生成されます。
FQDN ではなくホスト名のみを使って Tower にアクセスする場合に SAML を使用する設定はサポートされていません。このアクセスを実行するとエラーが発生し、そのエラーは tower.log ファイルにキャプチャーされ、詳細なトレースバック情報と共にブラウザーに表示されます。
本書の作成時点で、Tower はオペレーティングシステムが FIPS モードで動作するように設定されている場合の実行をサポートしていません。
ライブイベントのステータスドットは、何かの問題が生じると 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 をクリックすると、このエラーが残ります。
Ansible 3.2 には、Ansible 2.4 との互換性を持つ Microsoft Azure のバインディングが含まれています。しかし、これらのバインディングは Ansible 2.3、Tower 3.1、およびそれ以前のバージョンとは動作しません。Anbile Tower 3.2 以上のバージョンで Azure を使用している場合は、Ansible 2.4 以上を使用する必要があります。
完全にローカルの 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 のバンドルインストーラーを使用している場合、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
または serial
キーワードを使用すると、ジョブは実行されますが、ジョブの詳細ページには正常に表示されません。
詳細については、次のリンクを参照してください: https://docs.ansible.com/ansible/playbooks_strategies.html
ソーシャル認証を使用してログインするユーザーは削除されており、ユーザーは、システム管理者がユーザーが再度ログインできるように cleanup_deleted
アクションを days=0
の設定で実行するまで再度ログインできず、再作成されることはありません。cleanup_deleted
が実行されると、Tower は ansible-tower-service restart
コマンドを使用して再起動される必要があります。cleanup_deleted
アクションの実行前に削除されているアカウントはログインの試行時に「アカウントが非アクティブです」というメッセージを受信します。
ソース制御プロジェクトのインベントリーの使用時の Vault 処理された変数の使用は現在サポートされていません。
Red Hat Enterprise Linux 7.2 または 7.3 EUS システムでのインストール時に、「Install the Tower RPM」のステップでインストールが依存関係のエラーを出して失敗する可能性があります。
この場合、https://access.redhat.com/errata/RHBA-2017:1929 を手動で適用してから Ansible Tower をインストールする必要があります。