RHEL のシステムロールを使用した管理タスクおよび設定タスク
Red Hat Ansible Automation Platform Playbook を使用して RHEL システムロールを適用して、システム管理タスクを実施します。
概要
オープンソースをより包含的に設定する
Red Hat は、コード、ドキュメント、および Web プロパティーにおける問題のある用語の修正に努めています。取り組みの開始として、マスター、スレーブ、ブラックリスト、ホワイトリストの 4 つの用語の修正に取り組みます。このため、これらの変更は今後の複数のリリースに対して段階的に実施されます。詳細は、弊社の CTO のメッセージを参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 RHEL システムロールの使用
本セクションでは、RHEL システムロールの概要を説明します。また、Ansible Playbook を使用して特定のロールを適用し、さまざまなシステム管理タスクを実行する方法を説明します。
1.1. RHEL システムロールの概要
RHEL システムロールは、Ansible ロールおよびモジュールのコレクションです。RHEL システムロールは、複数の RHEL システムをリモートで管理するための設定インターフェースを提供します。このインターフェースは、RHEL の複数のバージョンにわたるシステム設定の管理と、新しいメジャーリリースの導入を可能にします。
Red Hat Enterprise Linux 8 のインターフェースは、現在、以下のロールから構成されます。
- kdump
- network
- selinux
- storage
- certificate
- kernel_settings
- logging
- metrics
- nbde_client and nbde_server
- timesync
- tlog
これらのロールはすべて、AppStream
リポジトリーで利用可能な rhel-system-roles
パッケージで提供されます。
関連情報
- RHEL システムロールの概要は、Red Hat ナレッジベースアーティクル 「Red Hat Enterprise Linux (RHEL) System Roles」 を参照してください。
-
特定のロールの詳細は、
/usr/share/doc/rhel-system-roles
ディレクトリーのドキュメントを参照してください。本書はrhel-system-roles
パッケージで自動的にインストールされます。 - 「SELinux システムロールの概要」
- 「ストレージロールの概要」
1.2. RHEL システムロールの用語
このドキュメントでは、以下の用語を確認できます。
システムロールの用語
- Ansible Playbook
- Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語です。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。
- コントロールノード
- Ansible がインストールされているマシン。コマンドおよび Playbook を実行でき、すべてのコントロールノードから /usr/bin/ansible または /usr/bin/ansible-playbook を起動します。Python がインストールされているすべてのコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、およびサーバーですべての Ansible を実行できます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを使用できます。
- インベントリー
- 管理対象ノードの一覧。インベントリーファイルは「ホストファイル」とも呼ばれます。インベントリーでは、各管理対象ノードに対して IP アドレスなどの情報を指定できます。また、インベントリーは管理ノードを編成し、簡単にスケーリングできるようにグループの作成およびネスト化が可能です。インベントリーについての詳細は、「インベントリーの操作」セクションを参照してください。
- 管理ノード
- Ansible で管理するネットワークデバイス、サーバー、またはその両方。管理対象ノードは、「ホスト」と呼ばれることもあります。Ansible が管理ノードにはインストールされません。
1.3. ロールの適用
以下の手順では、特定のロールを適用する方法を説明します。
前提条件
rhel-system-roles
パッケージが、コントロールノードとして使用するシステムにインストールされている。# yum install rhel-system-roles
Ansible Engine リポジトリーが有効になり、コントロールノードとして使用するシステムに
ansible
パッケージがインストールされている。RHEL システムロールを使用する Playbook を実行するには、ansible
パッケージが必要です。Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンを使用できます。この場合は、次の手順を実行します。
RHEL Ansible Engine リポジトリーを有効にします。
# subscription-manager refresh # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
- Red Hat Ansible Engine のサブスクリプションをお持ちの場合は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 に記載されている手順を行ってください。
Ansible Playbook を作成できる。
Playbook は、Ansible の設定、デプロイメント、およびオーケストレーションの言語を表します。Playbook を使用すると、リモートマシンの設定を宣言して管理したり、複数のリモートマシンをデプロイしたり、手動で順番を付けたプロセスの手順をまとめたりできます。
Playbook は、1 つ以上の
play
の一覧です。すべてのplay
には、Ansible の変数、タスク、またはロールが含まれます。Playbook は人が判読でき、
YAML
形式で表現されます。Playbook の詳細は、Ansible ドキュメント を参照してください。
手順
必要なロールを含む Ansible Playbook を作成します。
以下の例は、特定の
play
のroles:
オプションを使用してロールを使用する方法を示しています。--- - hosts: webservers roles: - rhel-system-roles.network - rhel-system-roles.timesync
Playbook でロールを使用する方法は、Ansible ドキュメント を参照してください。
Playbook の例は 「Ansible examples」を参照してください。
注記すべてのロールには README ファイルが含まれます。このファイルには、ロールや、サポートされるパラメーター値の使用方法が記載されています。ロールのドキュメントディレクトリーで、特定ロール用の Playbook のサンプルを見つけることもできます。このようなドキュメンテーションディレクトリーは、
rhel-system-roles
パッケージでデフォルトで提供され、以下の場所に置かれます。/usr/share/doc/rhel-system-roles/SUBSYSTEM/
SUBSYSTEM は、
selinux
、kdump
、network
、timesync
、またはstorage
などの必要なロールの名前に置き換えます。Playbook の構文を確認します。
#
ansible-playbook --syntax-check name.of.the.playbook
ansible-playbook
コマンドは、Playbook の構文の検証に使用できる--syntax-check
オプションを提供します。ansible-playbook
コマンドを実行して、ターゲットホストで Playbook を実行します。#
ansible-playbook -i name.of.the.inventory
name.of.the.playbookインベントリーは、Ansible が有効なシステムの一覧です。インベントリーの作成方法と使用方法は、Ansible ドキュメント を参照してください。
インベントリーがない場合は、
ansible-playbook
の実行時に作成できます。Playbook を実行するターゲットホストが 1 つしかない場合は、次のコマンドを実行します。
# ansible-playbook -i host1, name.of.the.playbook
Playbook を実行するターゲットホストが複数になる場合は、次のコマンドを実行します。
# ansible-playbook -i host1,host2,....,hostn name.of.the.playbook
関連情報
-
ansible-playbook
コマンドの使用方法は、man ページのansible-playbook
を参照してください。
1.4. 関連情報
- RHEL システムロールの概要は、Red Hat ナレッジベースアーティクル 「Red Hat Enterprise Linux (RHEL) System Roles」 を参照してください。
- 「RHEL システムロールを使用したローカルストレージの管理」
- 「複数のシステムへの同じ SELinux 設定のデプロイメント」
第2章 RHEL システムロールのインストール
システムロールの使用を開始する前に、システムにインストールする必要があります。
2.1. システムへの RHEL システムロールのインストール
この段落は、手順モジュールの紹介 (手順の簡単な説明) です。
前提条件
- Red Hat Ansible Engine のサブスクリプションを利用している。「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。
- コントロールノードとして使用するシステムに Ansible パッケージがインストールされている。
手順
rhel-system-roles
パッケージを、コントロールノードとして使用するシステムにインストールします。# yum install rhel-system-roles
Red Hat Ansible Engine サブスクリプションをお持ちでない場合は、Red Hat Enterprise Linux サブスクリプションで提供される Red Hat Ansible Engine の限定サポートバージョンを使用できます。この場合は、次の手順を実行します。
RHEL Ansible Engine リポジトリーを有効にします。
# subscription-manager refresh # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
結果として、Ansible の Playbook を作成できます。
関連情報
- RHEL システムロールの概要は、「Red Hat Enterprise Linux (RHEL) System Roles」 を参照してください。
- ansible-playbook コマンドの使用方法は、man ページの ansible-playbook を参照してください。
第3章 Ansible ロールを使用したカーネルパラメーターの永続的な設定
Red Hat Ansible Engine の詳しい知識がある経験のあるユーザーは、kernel_settings
ロールを使用して、複数のクライアントにカーネルパラメーターを一度に設定することができます。この解決策は以下のとおりです。
- 効率的な入力設定を持つ使いやすいインターフェースを提供します。
- すべてのカーネルパラメーターを 1 か所で保持します。
コントロールマシンから kernel_settings
ロールを実行すると、カーネルパラメーターはすぐに管理システムに適用され、再起動後も維持されます。
3.1. カーネル設定ロールの概要
RHEL システムロールは、複数のシステムをリモートで管理する一貫した構成インターフェースを提供するAnsible Automation Platformのロールおよびモジュールの集合です。
kernel_settings
システムロールを使用してカーネルの自動設定に、RHEL システムロールが導入されました。rhel-system-roles
パッケージには、このシステムロールと参考ドキュメントも含まれます。
カーネルパラメーターを自動的に 1 つ以上のシステムに適用するには、Playbook で選択したロール変数を 1 つ以上使用して、kernel_settings
ロールを使用します。Playbook は人間が判読でき、YAML 形式で記述される 1 つ以上のプレイの一覧です。
インベントリーファイルを使用して、Ansible Engine が Playbook に従って設定するシステムセットを定義することができます。
kernel_settings
ロールを使用して、以下を設定できます。
-
kernel_settings_sysctl
ロールを使用したカーネルパラメーター -
kernel_settings_sysfs
ロールを使用したさまざまなカーネルサブシステム、ハードウェアデバイス、およびデバイスドライバー -
systemd
サービスマネージャーの CPU アフィニティーを、kernel_settings_systemd_cpu_affinity
ロール変数を使用してフォーク処理します。 -
kernel_settings_transparent_hugepages
およびkernel_settings_transparent_hugepages_defrag
のロール変数を使用したカーネルメモリーサブシステムの Transparent Huge Page
関連情報
-
kernel_settings
ロール変数および Playbook の例については、rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/kernel_settings/
ディレクトリーにあるREADME.md
ファイルおよびREADME.html
ファイルを参照してください。 - Playbook の詳細は、Ansible ドキュメントの 「Working with playbooks」 を参照してください。
- インベントリーの作成および使用に関する詳細は、Ansible ドキュメントの 「How to build your inventory」 を参照してください。
3.2. カーネル設定ロールを使用した選択したカーネルパラメーターの適用
以下の手順に従って、Ansible Playbook を準備および適用し、複数の管理システムで永続化の影響でカーネルパラメーターをリモートに設定します。
前提条件
-
Red Hat Ansible Engine サブスクリプションが、
kernel_settings
ロールの実行元となる コントロールマシン とも呼ばれるシステムに割り当てられている。詳細は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。 - コントロールマシンで Ansible Engine リポジトリーが有効になっている。
Ansible Engine がコントロールマシンにインストールされている。
注記Ansible Engine を、管理ホスト とも呼ばれるシステムにインストールする必要はありません。ここでは、カーネルパラメーターを設定する必要があります。
-
rhel-system-roles
パッケージがコントロールマシンにインストールされている。 - 管理ホストのインベントリーがコントロールマシンに存在し、Ansible Engine がそれらのホストに接続できる。
手順
必要に応じて、図の目的で
inventory
ファイルを確認します。# cat /home/jdoe/<ansible_project_name>/inventory [testingservers] pdoe@192.168.122.98 fdoe@192.168.122.226 [db-servers] db1.example.com db2.example.com [webservers] web1.example.com web2.example.com 192.0.2.42
ファイルは
[testingservers]
グループと他のグループを定義します。これにより、特定のシステムのコレクションに対して Ansible Engine をより効果的に実行できます。Ansible Engine 操作のデフォルトおよび権限昇格を設定するための設定ファイルを作成します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi /home/jdoe/<ansible_project_name>/ansible.cfg
以下の内容をファイルに挿入します。
[defaults] inventory = ./inventory [privilege_escalation] become = true become_method = sudo become_user = root become_ask_pass = true
[defaults]
セクションは、管理対象ホストのインベントリーファイルへのパスを指定します。[privilege_escalation]
セクションでは、指定した管理対象ホストのユーザー権限がroot
に移行されることを定義します。これは、カーネルパラメーターを正常に設定するために必要です。Ansible Playbook を実行すると、ユーザーパスワードの入力が求められます。管理対象ホストへの接続後に、sudo
によりroot
に自動的に切り替わります。
kernel_settings
ロールを使用する Ansible Playbook を作成します。新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi /home/jdoe/<ansible_project_name>/kernel_roles.yml
このファイルは Playbook を表し、通常は、
inventory
ファイルから選択した特定の管理対象ホストに対して実行される、プレイ とも呼ばれるタスクの順序付きリストが含まれます。以下の内容をファイルに挿入します。
--- - name: Configure kernel settings hosts: testingservers vars: kernel_settings_sysctl: - name: fs.file-max value: 400000 - name: kernel.threads-max value: 65536 kernel_settings_sysfs: - name: /sys/class/net/lo/mtu value: 65000 kernel_settings_transparent_hugepages: madvise roles: - linux-system-roles.kernel_settings
name
キーは任意です。任意の文字列をラベルとしてプレイに関連付け、プレイの対象を特定します。プレイのhosts
キーは、プレイを実行するホストを指定します。このキーの値または値は、管理対象ホストの個別名またはinventory
ファイルで定義されているホストのグループとして指定できます。vars
セクションは、設定する必要がある、選択したカーネルパラメーター名および値が含まれる変数の一覧を表します。roles
キーは、vars
セクションで説明されているパラメーターおよび値を設定するシステムロールを指定します。注記必要に応じて、Playbook のカーネルパラメーターとその値を変更することができます。
必要に応じて、プレイ内の構文が正しいことを確認します。
# ansible-playbook --syntax-check kernel-roles.yml playbook: kernel-roles.yml
以下の例では、Playbook の検証が成功したことを示しています。
Playbook を実行します。
# ansible-playbook kernel-roles.yml BECOME password: PLAY [Configure kernel settings] ... PLAY RECAP ** fdoe@192.168.122.226 : ok=10 changed=4 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0 pdoe@192.168.122.98 : ok=10 changed=4 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0
Ansible Engine が Playbook を実行する前に、パスワードの入力を求められます。これにより、管理対象ホストのユーザーが
root
に切り替わります。これは、カーネルパラメーターの設定に必要です。recap セクションは、すべての管理対象ホストのプレイが正常に終了したこと (
failed=0
)、および 4 つのカーネルパラメーターが適用されたこと (changed=4
) を示しています。- 管理対象ホストを再起動して、影響を受けるカーネルパラメーターをチェックし、変更が適用され、再起動後も維持されていることを確認します。
関連情報
- RHEL システムロールの詳細は、「RHEL システムロールの使用」 を参照してください。
-
kernel_settings
で現在サポートされている変数すべての詳細は、/usr/share/doc/rhel-system-roles/kernel_settings/
ディレクトリーのREADME.html
ファイルおよびREADME.md
ファイルを参照してください。 - Ansible インベントリーの詳細は、Ansible ドキュメントの 「Working with Inventory」 を参照してください。
- Ansible 設定ファイルの詳細は、Ansible ドキュメントの 「Configuring Ansible」 を参照してください。
- Ansible Playbook の詳細は、Ansible ドキュメントの 「Working With Playbooks」 を参照してください。
- Ansible 変数の詳細は、Ansible ドキュメントの 「Using Variables」 を参照してください。
- Ansible ロールの詳細は、Ansible ドキュメントの 「Roles」 を参照してください。
第4章 システムロールを使用したネットワーク接続の設定
RHEL の network
システムロールを使用すると、管理者は Ansible を使用してネットワーク関連の設定および管理タスクを自動化できます。
4.1. イーサネット接続の設定
本セクションでは、静的および動的の IP アドレスでイーサネット接続を構成するさまざまな方法を説明します。
4.1.1. RHEL システムロールを使用した静的イーサネット接続の設定
この手順では、RHEL システムロールを使用して、以下の設定で enp7s0
インターフェースのイーサネット接続をリモートに追加する方法を説明します。これには、Ansible Playbook を実行します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ192.0.2.1
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
192.0.2.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
192.0.2.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
Ansible コントロールノードで以下の手順を実行します。
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが付与される。 - ホストは NetworkManager を使用してネットワークを設定している。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/ethernet-static-IP.yml
ファイルを以下の内容で作成します。--- - name: Configure an Ethernet connection with static IP hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: - name: enp7s0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/ethernet-static-IP.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/ethernet-static-IP.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.1.2. RHEL システムロールを使用した動的イーサネット接続の設定
この手順では、RHEL システムロールを使用して、Ansible Playbook を実行して enp7s0
インターフェースの動的イーサネット接続をリモートに追加する方法を説明します。この設定により、ネットワーク接続は、DHCP サーバーからこの接続の IP 設定を要求するようになりました。Ansible コントロールノードで以下の手順を実行します。
前提条件
- DHCP サーバーはネットワークで使用できる。
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが付与される。 - ホストは NetworkManager を使用してネットワークを設定している。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/ethernet-dynamic-IP.yml
Playbook を以下の内容で作成します。--- - name: Configure an Ethernet connection with dynamic IP hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: - name: enp7s0 type: ethernet autoconnect: yes ip: dhcp4: yes auto6: yes state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/ethernet-dynamic-IP.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/ethernet-dynamic-IP.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.2. 802.1X 標準を使用したネットワークへの RHEL クライアントの認証
管理者は、IEEE 802.1X 標準に基づいてポートベースのネットワークアクセス制御 (NAC) を使用して、承認されていない LAN および Wi-Fi クライアントからネットワークを保護します。本セクションの手順では、ネットワーク認証を設定するさまざまなオプションを説明します。
4.2.1. RHEL システムロールを使用した 802.1X ネットワーク認証による静的イーサネット接続の設定
RHEL システムロールを使用すると、802.1X 標準を使用してクライアントを認証するイーサネット接続の作成を自動化できます。この手順では、以下の設定で enp1s0
インターフェースのイーサネット接続をリモートに追加する方法を説明します。これには、Ansible Playbook を実行します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ192.0.2.1
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
192.0.2.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
192.0.2.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
-
TLS
Extensible Authentication Protocol (EAP) を使用した 802.1X ネットワーク認証
Ansible コントロールノードで以下の手順を実行します。
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが必要。 - ネットワークは 802.1X ネットワーク認証をサポートしている。
- 管理ノードは NetworkManager を使用している。
TLS 認証に必要な以下のファイルがコントロールノードにある。
-
/srv/data/client.key
ファイルに保存されているクライアントキー。 -
/srv/data/client.crt
ファイルに保存されているクライアント証明書。 -
/srv/data/ca.crt
ファイルに保存されている認証局 (CA) の証明書。
-
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/enable-802.1x.yml
Playbook を以下の内容で作成します。--- - name: Configure an Ethernet connection with 802.1X authentication hosts: node.example.com become: true tasks: - name: Copy client key for 802.1X authentication copy: src: "/srv/data/client.key" dest: "/etc/pki/tls/private/client.key" mode: 0600 - name: Copy client certificate for 802.1X authentication copy: src: "/srv/data/client.crt" dest: "/etc/pki/tls/certs/client.crt" - name: Copy CA certificate for 802.1X authentication copy: src: "/srv/data/ca.crt" dest: "/etc/pki/ca-trust/source/anchors/ca.crt" - include_role: name: linux-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 192.0.2.1/24 - 2001:db8:1::1/64 gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com ieee802_1x: identity: user_name eap: tls private_key: "/etc/pki/tls/private/client.key" private_key_password: "password" client_cert: "/etc/pki/tls/certs/client.crt" ca_cert: "/etc/pki/ca-trust/source/anchors/ca.crt" domain_suffix_match: example.com state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/enable-802.1x.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/ethernet-static-IP.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
802.1X パラメーターの詳細は、
/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルのieee802_1x
セクションを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.3. デフォルトのゲートウェイ設定の管理
デフォルトゲートウェイは、他のルートがパケットの宛先と一致する場合にネットワークパケットを転送するルーターです。ローカルネットワークでは、通常、デフォルトゲートウェイは、インターネットの近くの 1 ホップのホストです。
4.3.1. システムロールを使用して、既存の接続でデフォルトのゲートウェイを設定
networking
の RHEL システムロールを使用して、デフォルトゲートウェイを設定できます。
network
の RHEL システムロールを使用するプレイを実行すると、設定がプレイで指定されたものにマッチしない場合に、システムロールは、既存の接続プロファイルを上書きして上書きします。したがって、IP 設定がすでに存在している場合でも、再生でネットワーク接続プロファイルの設定全体を指定する必要があります。それ以外の場合は、ロールはこれらの値をデフォルト値にリセットします。
この手順では、すでに存在するかどうかに応じて、以下の設定で enp1s0
接続プロファイルを作成または更新します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ198.51.100.20
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
198.51.100.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
198.51.100.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが付与される。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/ethernet-connection.yml
Playbook を以下の内容で作成します。--- - name: Configure an Ethernet connection with static IP and default gateway hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 198.51.100.20/24 - 2001:db8:1::1/64 gateway4: 198.51.100.254 gateway6: 2001:db8:1::fffe dns: - 198.51.100.200 - 2001:db8:1::ffbb dns_search: - example.com state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/ethernet-connection.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/ethernet-connection.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.4. 静的ルートの設定
デフォルトでは、デフォルトゲートウェイが設定されていると、Red Hat Enterprise Linux は、ホストに直接接続されていないネットワークのトラフィックをデフォルトゲートウェイに転送します。静的ルートを使用して、Red Hat Enterprise Linux が特定のホストまたはネットワークのトラフィックをデフォルトゲートウェイとは別のルーターに転送するように設定できます。本セクションでは、静的ルートを設定するさまざまなオプションを説明します。
4.4.1. RHEL システムロールを使用した静的ルートの設定
networking
の RHEL システムロールを使用して、静的ルートを設定できます。
network
の RHEL システムロールを使用するプレイを実行すると、設定がプレイで指定されたものにマッチしない場合に、システムロールは、既存の接続プロファイルを上書きして上書きします。したがって、IP 設定がすでに存在している場合でも、再生でネットワーク接続プロファイルの設定全体を指定する必要があります。それ以外の場合は、ロールはこれらの値をデフォルト値にリセットします。
この手順では、すでに存在するかどうかに応じて、以下の設定で enp7s0
接続プロファイルを作成または更新します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ198.51.100.20
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
198.51.100.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
198.51.100.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
静的ルート:
-
ゲートウェイ
198.51.100.1
の192.0.2.0/24
-
203.0.113.0/24
のゲートウェイ198.51.100.2
-
ゲートウェイ
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが付与される。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/add-static-routes.yml
Playbook を以下の内容で作成します。--- - name: Configure an Ethernet connection with static IP and additional routes hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: - name: enp7s0 type: ethernet autoconnect: yes ip: address: - 198.51.100.20/24 - 2001:db8:1::1/64 gateway4: 198.51.100.254 gateway6: 2001:db8:1::fffe dns: - 198.51.100.200 - 2001:db8:1::ffbb dns_search: - example.com route: - network: 192.0.2.0 prefix: 24 gateway: 198.51.100.1 - network: 203.0.113.0 prefix: 24 gateway: 198.51.100.2 state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/add-static-routes.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/add-static-routes.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
検証手順
ルーティングテーブルを表示します。
#
ip -4 route
default via 198.51.100.254 dev enp7s0 proto static metric 100 192.0.2.0/24 via 198.51.100.1 dev enp7s0 proto static metric 100 203.0.113.0/24 via 198.51.100.2 dev enp7s0 proto static metric 100 ...
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.5. VLAN タグの設定
本セクションでは、仮想ローカルエリアネットワーク (VLAN) を設定する方法を説明します。VLAN は、物理ネットワーク内の論理ネットワークです。VLAN インターフェースは、インターフェースを通過する際に VLAN ID でパケットをタグ付けし、返信パケットのタグを削除します。
VLAN インターフェースを、イーサネット、ボンド、チーム、ブリッジデバイスなどの別のインターフェースに作成します。このインターフェースは、親インターフェース
と呼ばれます。
4.5.1. システムロールを使用した VLAN タグの設定
networking
の RHEL システムロールを使用して、VLAN タグ付けを設定できます。この手順では、イーサネット接続と、このイーサネット接続を使用する ID 10
の VLAN を追加する方法を説明します。親デバイスとして、VLAN 接続には IP、デフォルトゲートウェイ、および DNS 設定が含まれます。
環境に応じて、play を適宜調整します。以下に例を示します。
-
ボンディングなどの他の接続で VLAN をポートとして使用するには、
ip
属性を省略し、親設定で IP 設定を設定します。 -
VLAN でチーム、ブリッジ、またはボンディングデバイスを使用するには、
interface_name
と VLAN で使用するポートのtype
属性を調整します。
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に
root
以外のリモートユーザーを使用する場合は、管理ノードで適切なsudo
パーミッションが付与される。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/vlan-ethernet.yml
Playbook を以下の内容で作成します。--- - name: Configure a VLAN that uses an Ethernet connection hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: # Add an Ethernet profile for the underlying device of the VLAN - name: enp1s0 type: ethernet interface_name: enp1s0 autoconnect: yes state: up ip: dhcp4: no auto6: no # Define the VLAN profile - name: vlan10 type: vlan ip: address: - "192.0.2.1/24" - "2001:db8:1::1/64" gateway4: 192.0.2.254 gateway6: 2001:db8:1::fffe dns: - 192.0.2.200 - 2001:db8:1::ffbb dns_search: - example.com vlan_id: 10 parent: enp1s0 state: up
VLAN プロファイルの
parent
属性は、enp1s0
デバイス上で動作する VLAN を設定します。Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/vlan-ethernet.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/vlan-ethernet.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
network_connections
で使用されるパラメーターの詳細と、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
4.6. ethtool オフロード機能の設定
ネットワークインターフェースカードは、TCP オフロードエンジン (TOE) を使用して、ネットワークコントローラーへの特定の操作をオフロードして、ネットワークのスループットを向上できます。
本項では、オフロード機能の設定方法について説明します。
4.6.1. システムロールを使用した ethtool 機能の設定
networking
の RHEL システムロールを使用して、NetworkManager 接続の ethtool
機能を設定できます。
network
の RHEL システムロールを使用するプレイを実行すると、設定がプレイで指定されたものにマッチしない場合に、システムロールは、既存の接続プロファイルを上書きして上書きします。したがって、IP 設定などがすでに存在している場合でも、常にネットワーク接続プロファイルの設定全体が指定されます。それ以外の場合は、ロールはこれらの値をデフォルト値にリセットします。
この手順では、すでに存在するかどうかに応じて、以下の設定で enp1s0
接続プロファイルを作成または更新します。
-
静的 IPv4 アドレス:
/24
サブネットマスクを持つ198.51.100.20
-
静的 IPv6 アドレス:
2001:db8:1::1
(/64
サブネットマスクあり) -
IPv4 デフォルトゲートウェイ:
198.51.100.254
-
IPv6 デフォルトゲートウェイ:
2001:db8:1::fffe
-
IPv4 DNS サーバー:
198.51.100.200
-
IPv6 DNS サーバー:
2001:db8:1::ffbb
-
DNS 検索ドメイン:
example.com
ethtool
機能:- 汎用受信オフロード(GRO): 無効
- Generic segmentation offload(GSO): 有効化
- SCTP(TX Stream Control Transmission Protocol)segmentation: disabled
前提条件
-
ansible
パッケージおよびrhel-system-roles
パッケージがコントロールノードにインストールされている。 -
Playbook の実行時に root 以外のリモートユーザーを使用する場合は、管理ノードで適切な
sudo
パーミッションが付与される。
手順
Playbook の命令を実行するホストのインベントリーがまだ指定されていない場合は、そのホストの IP または名前を Ansible インベントリーファイル
/etc/ansible/hosts
に追加します。node.example.com
~/configure-ethernet-device-with-ethtool-features.yml
Playbook を以下の内容で作成します。--- - name. Configure an Ethernet connection with ethtool features hosts: node.example.com become: true tasks: - include_role: name: linux-system-roles.network vars: network_connections: - name: enp1s0 type: ethernet autoconnect: yes ip: address: - 198.51.100.20/24 - 2001:db8:1::1/64 gateway4: 198.51.100.254 gateway6: 2001:db8:1::fffe dns: - 198.51.100.200 - 2001:db8:1::ffbb dns_search: - example.com ethtool: feature: gro: "no" gso: "yes" tx_sctp_segmentation: "no" state: up
Playbook を実行します。
root
ユーザーとして管理対象ホストに接続するには、次のコマンドを実行します。#
ansible-playbook -u root ~/configure-ethernet-device-with-ethtool-features.yml
管理ホストにユーザーとして接続するには、次のコマンドを実行します。
#
ansible-playbook -u user_name
--ask-become-pass ~/configure-ethernet-device-with-ethtool-features.yml--ask-become-pass
オプションは、ansible-playbook
コマンドが-u user_name
オプションで定義したユーザーのsudo
パスワードを要求するようにします。
-u user_name
オプションを指定しないと、ansible-playbook
は、コントロールノードに現在ログインしているユーザーとして管理ホストに接続します。
関連情報
-
ethtool
の完全なリストと、network_connections
で使用されるパラメーターの詳細、システムロールnetwork
に関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.network/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
第5章 システムロールを使用した SElinux の設定
5.1. SELinux システムロールの概要
RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した構成インターフェースを提供する Ansible ロールおよびモジュールの集合です。SELinux システムロールは、以下のアクションを有効にします。
- SELinux ブール値、ファイルコンテキスト、ポート、およびログインに関連するローカルポリシーの変更を消去します。
- SELinux ポリシーブール値、ファイルコンテキスト、ポート、およびログインの設定
- 指定されたファイルまたはディレクトリーでファイルコンテキストを復元します。
以下の表は、SELinux システムロールで利用可能な入力変数の概要を示しています。
表5.1 SELinux システムロール変数
ロール変数 | 説明 | CLI の代替手段 |
---|---|---|
selinux_policy | ターゲットプロセスまたは複数レベルのセキュリティー保護を保護するポリシーを選択します。 |
|
selinux_state |
SELinux モードを切り替えます。 |
|
selinux_booleans |
SELinux ブール値を有効または無効にします。 |
|
selinux_fcontexts |
SELinux ファイルコンテキストマッピングを追加または削除します。 |
|
selinux_restore_dirs | ファイルシステムツリー内の SELinux ラベルを復元します。 |
|
selinux_ports |
ポートに SELinux ラベルを設定します。 |
|
selinux_logins |
ユーザーを SELinux ユーザーマッピングに設定します。 |
|
rhel-system-roles
パッケージによりインストールされる /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml
のサンプル Playbook は、Enforcing モードでターゲットポリシーを設定する方法を示しています。Playbook は、複数のローカルポリシーの変更を適用し、tmp/test_dir/
ディレクトリーのファイルコンテキストを復元します。
関連情報
-
SELinux ロール変数の詳細は、
rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/selinux/
ディレクトリーのREADME.md
またはREADME.html
ファイルを参照してください。 - RHEL システムロールの詳細は、「RHEL のシステムロールの概要」 を参照してください。
5.2. SELinux システムロールを使用した複数のシステムに SELinux 設定を適用
以下の手順に従って、検証した SELinux 設定を使用して Ansible Playbook を準備し、適用します。
前提条件
- Red Hat Ansible Engine のサブスクリプションがシステムに割り当てられている。詳細は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。
手順
RHEL Ansible リポジトリーを有効にします。以下に例を示します。
# subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
RHEL システムロールをインストールします。
# yum install rhel-system-roles
SELinux システムロールで Playbook を適用します。
以下のコマンドは、
rhel-system-roles
パッケージに含まれる Playbook のサンプルを適用します。この Playbook をテンプレートとして使用できます。# ansible-playbook -i host1,host2,host3 /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml
関連情報
-
詳細は、
rhel-system-roles
パッケージをインストールして、/usr/share/doc/rhel-system-roles/selinux/
ディレクトリーおよび/usr/share/ansible/roles/rhel-system-roles.selinux/
ディレクトリーを参照してください。
第6章 Logging システムロールの使用
システム管理者は、Logging システムロールを使用して、RHEL ホストをロギングサーバーとして設定し、多くのクライアントシステムからログを収集できます。
6.1. Logging システムロール
Logging システムロールを使用すると、ローカルおよびリモートホストにロギング設定をデプロイできます。
Logging システムロールを 1 つ以上のシステムに適用するには、Playbook でロギング設定を定義します。Playbook は、1 つ以上の play の一覧です。Playbook は YAML 形式で表現され、人が判読できるようになっています。Playbook の詳細は、Ansible ドキュメントの 「Working with playbooks」 を参照してください。
Ansible が Playbook に従って設定するシステムのセットは、インベントリーファイル で定義されます。インベントリーの作成および使用に関する詳細は、Ansible ドキュメントの 「How to build your inventory」 を参照してください。
ロギングソリューションは、ログと複数のログ出力を読み取る複数の方法を提供します。
たとえば、ロギングシステムは以下の入力を受け取ることができます。
- ローカルファイル
-
systemd/journal
- ネットワーク上で別のロギングシステム
さらに、ロギングシステムでは以下を出力できます。
-
/var/log
ディレクトリーのローカルファイルに保存されるログ - Elasticsearch に送信されるログ
- 別のロギングシステムに転送されるログ
logging システムロールを使用すると、必要に応じて入力と出力を組み合わせることができます。たとえば、journal
からの入力をローカルのファイルに保存しつつも、複数のファイルから読み込んだ入力を別のロギングシステムに転送してそのローカルのログファイルに保存するようにロギングソリューションを設定できます。
6.2. Logging システムロールのパラメーター
Logging システムロール Playbook では、logging_inputs
パラメーターで入力を、logging_outputs
パラメーターで出力を、そして logging_flows
パラメーターで入力と出力の関係を定義します。Logging システムロールは、ロギングシステムの追加設定オプションで、上記の変数を処理します。暗号化を有効にすることもできます。
現在、Logging システムロールで利用可能な唯一のロギングシステムは Rsyslog です。
logging_inputs
: ロギングソリューションの入力リスト。-
name
: 入力の一意の名前。logging_flows
入力一覧および生成されたconfig
ファイル名の一部で使用されます。 type
: 入力要素のタイプ。type は、roles/rsyslog/{tasks,vars}/inputs/
のディレクトリー名に対応するタスクタイプを指定します。basics
:systemd
ジャーナルまたはunix
ソケットからの入力を設定する入力。-
kernel_message
:true
に設定された場合はimklog
を読み込みます。デフォルトはfalse
です。 -
use_imuxsock
:imjournal
の代わりにimuxsock
を使用します。デフォルトはfalse
です。 -
ratelimit_burst
:ratelimit_interval
内に出力できるメッセージの最大数。use_imuxsock
が false の場合、デフォルトで20000
に設定されます。use_imuxsock
が true の場合、デフォルトで200
に設定されます。 -
ratelimit_interval
:ratelimit_burst
を評価する間隔。use_imuxsock
が false の場合、デフォルトで 600 秒に設定されます。use_imuxsock
が true の場合、デフォルトで 0 に設定されます。0 はレート制限がオフであることを示します。 -
persist_state_interval
: ジャーナルの状態は、value
メッセージごとに永続化されます。デフォルトは10
です。use_imuxsock
が false の場合のみ、有効です。
-
-
files
: ローカルファイルからの入力を設定する入力。 -
remote
: ネットワークを介して、他のロギングシステムからの入力を設定する入力。
-
state
: 設定ファイルの状態。present
またはabsent
。デフォルトはpresent
です。
-
logging_outputs
: ロギングソリューションの出力一覧。-
files
: ローカルファイルへの出力を設定する出力。 -
forwards
: 別のロギングシステムへの出力を設定する出力。 -
remote_files
: 別のロギングシステムからの出力をローカルファイルに設定する出力。
-
logging_flows
:logging_inputs
とlogging_outputs
の関係を定義するフローの一覧。logging_flows
変数には以下が含まれます。-
name
: フローの一意の名前。 -
inputs
:logging_inputs
名の値の一覧。 -
outputs
:logging_outputs
名の値の一覧。
-
関連情報
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
)
6.3. ローカルの Logging システムロールの適用
以下の手順に従って、Red Hat Ansible Engine Playbook を準備および適用し、別個のマシンにロギングソリューションを設定します。各マシンはログをローカルに記録します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ロギングソリューションをデプロイするシステムに Red Hat Ansible Engine をインストールする必要はありません。
Playbook を実行するシステムに
rhel-system-roles
パッケージがある。注記デプロイ時に
rsyslog
がシステムロールによりインストールされるので、rsyslog
はインストールする必要はありません。- ロギングソリューションを設定するシステムを一覧表示するインベントリーファイルがある。
手順
必要なロールを定義する Playbook を作成します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi logging-playbook.yml
以下の内容を挿入します。
--- - name: Deploying basics input and implicit files output hosts: all roles: - linux-system-roles.logging vars: logging_inputs: - name: system_input type: basics logging_outputs: - name: files_output type: files logging_flows: - name: flow1 inputs: [system_input] outputs: [files_output]
特定のインベントリーで Playbook を実行します。
# ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml
ここでは、
-
inventory-file
はインベントリーファイルに置き換えます。 -
logging-playbook.yml
は、使用する Playbook に置き換えます。
-
検証
/etc/rsyslog.conf
ファイルの構文をテストします。# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
システムがログにメッセージを送信していることを確認します。
テストメッセージを送信します。
# logger test
/var/log/messages ログ
を表示します。以下に例を示します。# cat /var/log/messages Aug 5 13:48:31 hostname root[6778]: test
`hostname` はクライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は
root
) が含まれていることに注意してください。
6.4. Logging システムロールを使用したリモートロギングソリューションの適用
以下の手順に従って、Red Hat Ansible Engine Playbook を準備および適用し、リモートロギングソリューションを設定します。この Playbook では、1 つ以上のクライアントが systemd-journal
からログを取得し、リモートサーバーに転送します。サーバーは、remote_rsyslog
および remote_files
からリモート入力を受信し、リモートホスト名によって名付けられたディレクトリーのローカルファイルにログを出力します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ロギングソリューションをデプロイするシステムに Red Hat Ansible Engine をインストールする必要はありません。
Playbook を実行するシステムに
rhel-system-roles
パッケージがある。注記デプロイ時に
rsyslog
がシステムロールによりインストールされるので、rsyslog
はインストールする必要はありません。2 つ以上のシステムがある。
- 少なくとも 1 つはロギングサーバー
- 少なくとも 1 つはロギングクライアント
手順
必要なロールを定義する Playbook を作成します。
新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。
# vi logging-playbook.yml
以下の内容をファイルに挿入します。
--- - name: Deploying remote input and remote_files output hosts: server roles: - linux-system-roles.logging vars: logging_inputs: - name: remote_udp_input type: remote udp_ports: [ 601 ] - name: remote_tcp_input type: remote tcp_ports: [ 601 ] logging_outputs: - name: remote_files_output type: remote_files logging_flows: - name: flow_0 inputs: [remote_udp_input, remote_tcp_input] outputs: [remote_files_output] - name: Deploying basics input and forwards output hosts: clients roles: - linux-system-roles.logging vars: logging_inputs: - name: basic_input type: basics logging_outputs: - name: forward_output0 type: forwards severity: info target: host1.example.com udp_port: 601 - name: forward_output1 type: forwards facility: mail target: host1.example.com tcp_port: 601 logging_flows: - name: flows0 inputs: [basic_input] outputs: [forward_output0, forward_output1] [basic_input] [forward_output0, forward_output1]
host1.example.com
はロギングサーバーに置き換えます。注記必要に応じて、Playbook のパラメーターを変更することができます。
警告ロギングソリューションは、サーバーまたはクライアントシステムの SELinux ポリシーで定義され、ファイアウォールで開放されたポートでしか機能しません。デフォルトの SELinux ポリシーには、ポート 601、514、6514、10514、および 20514 が含まれます。別のポートを使用するには、「クライアントシステムとサーバーシステムで SELinux ポリシーを変更」します。システムロールを使用したファイアウォールの設定は、まだサポートされていません。
サーバーおよびクライアントを一覧表示するインベントリーファイルを作成します。
新しいファイルを作成してテキストエディターで開きます。以下に例を示します。
# vi inventory.ini
以下のコンテンツをインベントリーファイルに挿入します。
[servers] server ansible_host=host1.example.com [clients] client ansible_host=host2.example.com
*
host1.example.com
はロギングサーバー、*host2.example.com
はロギングクライアントになります。
インベントリーで Playbook を実行します。
# ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml
ここでは、
-
inventory.ini
はインベントリーファイルに置き換えます。 -
logging-playbook.yml
は作成した Playbook に置き換えます。
-
検証手順
クライアントとサーバーシステムの両方で、
/etc/rsyslog.conf
ファイルの構文をテストします。# rsyslogd -N 1 rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye.
クライアントシステムがサーバーにメッセージを送信することを確認します。
クライアントシステムで、テストメッセージを送信します。
# logger test
サーバーシステムで、
/var/log/messages
ログを表示します。以下に例を示します。# cat /var/log/messages Aug 5 13:48:31 host2.example.com root[6778]: test
host2.example.com
は、クライアントシステムのホスト名です。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合はroot
) が含まれていることに注意してください。
関連情報
- RHEL システムロールの使用
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
) - ナレッジベースの記事 「Red Hat Enterprise Linux (RHEL) System Roles」
6.5. 関連情報
- RHEL システムロールの使用
-
rhel-system-roles
パッケージでインストールされたドキュメント (/usr/share/ansible/roles/rhel-system-roles.logging/README.html
) - ナレッジベースの記事 「Red Hat Enterprise Linux (RHEL) System Roles」
第7章 Clevis および Tang のシステムロールの使用
7.1. Clevis および Tang のシステムロールの概要
RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した構成インターフェースを提供する Ansible ロールおよびモジュールの集合です。
RHEL 8.3 では、Clevis および Tang を使用した PBD (Policy-Based Decryption) ソリューションの自動デプロイメント用 Ansible ロールが導入されました。rhel-system-roles
パッケージには、これらのシステムロール、関連する例、リファレンスドキュメントが含まれます。
nbde_client
システムロールにより、複数の Clevis クライアントを自動的にデプロイできます。nbde_client
ロールは、Tang バインディングのみをサポートしており、現時点では TPM2 バインディングには使用できない点に留意してください。
nbde_server
ロールを使用すると、自動ディスク暗号化ソリューションの一部として、Tang サーバーをデプロイして管理できます。このロールは以下の機能をサポートします。
- Tang 鍵のローテーション
- Tang 鍵のデプロイおよびバックアップ
関連情報
-
NBDE (Network-Bound Disk Encryption) ロール変数の詳細は、
rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/nbde_client/
と/usr/share/doc/rhel-system-roles/nbde_server/
ディレクトリーのREADME.md
とREADME.html
ファイルを参照してください。 -
たとえば、system-roles Playbook の場合は、
rhel-system-roles
パッケージをインストールし、/usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/
ディレクトリーを参照してください。 - RHEL システムロールの詳細は、「RHEL のシステムロールの概要」 を参照してください。
7.2. 複数の Tang サーバーを設定する nbde_server システムロールの使用
以下の手順に従って、Tang-server 設定を含む Ansible Playbook を準備および適用します。
前提条件
- Red Hat Ansible Engine のサブスクリプションがシステムに割り当てられている。詳細は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。
手順
RHEL Ansible リポジトリーを有効にします。以下に例を示します。
# subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
RHEL システムロールをインストールします。
# yum install rhel-system-roles
Tang サーバーの設定が含まれる Playbook を準備します。ゼロから開始するか、または
/usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/
ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。# cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml
選択したテキストエディターで Playbook を編集します。以下に例を示します。
# vi my-tang-playbook.yml
必要なパラメーターを追加します。以下の Playbook の例では、Tang サーバーのデプロイとキーローテーションを確実に実行します。
--- - hosts: all vars: nbde_server_rotate_keys: yes roles: - linux-system-roles.nbde_server
終了した Playbook を適用します。
# ansible-playbook -i host1,host2,host3 my-tang-playbook.yml
関連情報
-
詳細は、
rhel-system-roles
パッケージをインストールして、/usr/share/doc/rhel-system-roles/nbde_server/
ディレクトリーおよびusr/share/ansible/roles/rhel-system-roles.nbde_server/
ディレクトリーを参照してください。
7.3. 複数の Clevis クライアントを設定する nbde_client システムロールの使用
手順に従って、Clevis-client 設定を含む Ansible Playbook を準備および適用します。
nbde_client
システムロールは、Tang バインディングのみをサポートします。これは、現時点では TPM2 バインディングに使用できないことを意味します。
前提条件
- Red Hat Ansible Engine のサブスクリプションがシステムに割り当てられている。詳細は、「Red Hat Ansible Engine のダウンロードおよびインストールの方法」 を参照してください。
手順
RHEL Ansible リポジトリーを有効にします。以下に例を示します。
# subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
Ansible Engine をインストールします。
# yum install ansible
RHEL システムロールをインストールします。
# yum install rhel-system-roles
Clevis クライアントの設定が含まれる Playbook を準備します。ゼロから開始するか、または
/usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/
ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。# cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml
選択したテキストエディターで Playbook を編集します。以下に例を示します。
# vi my-clevis-playbook.yml
必要なパラメーターを追加します。以下の Playbook の例では、2 つの Tang サーバーのうち少なくとも 1 台が利用可能な場合に、LUKS で暗号化した 2 つのボリュームを自動的にアンロックするように Clevis クライアントを設定します。
--- - hosts: all vars: nbde_client_bindings: - device: /dev/rhel/root key_file: /etc/luks/keyfile servers: - http://server1.example.com - http://server2.example.com - device: /dev/rhel/swap key_file: /etc/luks/keyfile servers: - http://server1.example.com - http://server2.example.com roles: - linux-system-roles.nbde_client
終了した Playbook を適用します。
# ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml
関連情報
-
パラメーターの詳細と、
nbde_client
ロールに関する追加情報は、rhel-system-roles
パッケージをインストールし、/usr/share/doc/rhel-system-roles/nbde_client/
および/usr/share/ansible/roles/rhel-system-roles.nbde_client/
ディレクトリーを参照してください。
第8章 RHEL システムロールを使用した証明書の要求
Certificate システムロールを使用すると、Red Hat Ansible Engine を使用して証明書の発行および管理ができます。
本章では、以下のトピックについて説明します。
8.1. Certificate システムロール
Certificate システムロールを使用すると、Red Hat Ansible Engine を使用して TLS 証明書と SSL 証明書の発行および更新を管理することができます。
ロールは certmonger
を証明書プロバイダーとして使用し、自己署名証明書の発行と更新、および IdM 統合認証局 (CA) の使用を現時点でサポートしています。
Certificate システムロールを使用すると、Ansible Playbook で以下の変数を使用できます。
- certificate_wait: タスクが証明書を発行するまで待機するかどうかを指定します。
- certificate_requests: 発行する各証明書とそのパラメーターを表す。
関連情報
-
certificate_requests
変数で使用されるパラメーターの詳細と、certificate
システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
ファイルを参照してください。 - RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの使用」 を参照してください。
8.2. Certificate システムロールを使用した新しい自己署名証明書の要求
Certificate システムロールを使用すると、Red Hat Ansible Engine を使用して自己署名証明書を発行することができます。
このプロセスは、certmonger
プロバイダーを使用し、getcert
コマンドで証明書を要求します。
デフォルトでは、certmonger
は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew
パラメーターを no
に設定すると無効にできます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記certificate
ソリューションをデプロイするシステムに Ansible をインストールする必要はありません。Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの使用」 を参照してください。
手順
オプション:
inventory.file
などのインベントリーファイルを作成します。$ touch inventory.file
インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。
[webserver] server.idm.example.com
Playbook ファイルを作成します (例:
request-certificate.yml
)。-
webserver
など、証明書を要求するホストを含むようにhosts
を設定します。 certificate_requests
変数を設定して以下を追加します。-
name
パラメーターを希望する証明書の名前 (mycert
など) に設定します。 -
dns
パラメーターを*.example.com
などの証明書に含むドメインに設定します。 -
ca
パラメーターをself-sign
に設定します。
-
roles
の下にrhel-system-roles.certificate
ロールを設定します。以下は、この例の Playbook ファイルです。
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: *.example.com ca: self-sign roles: - rhel-system-roles.certificate
-
- ファイルを保存します。
Playbook を実行します。
$ ansible-playbook -i inventory.file request-certificate.yml
関連情報
-
certificate_requests
変数で使用されるパラメーターの詳細と、certificate
システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
8.3. Certificate システムロールを使用した IdM CA からの新しい証明書の要求
Certificate システムロールを使用すると、統合認証局 (CA) がある IdM サーバーを使用しながら、Red Hat Ansible Engine を使用して証明書を発行できます。したがって、IdM を CA として使用する場合に、複数のシステムの証明書トラストチェーンを効率的かつ一貫して管理できます。
このプロセスは、certmonger
プロバイダーを使用し、getcert
コマンドで証明書を要求します。
デフォルトでは、certmonger
は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew
パラメーターを no
に設定すると無効にできます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記certificate
ソリューションをデプロイするシステムに Ansible をインストールする必要はありません。Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの使用」 を参照してください。
手順
オプション:
inventory.file
などのインベントリーファイルを作成します。$ touch inventory.file
インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。
[webserver] server.idm.example.com
Playbook ファイルを作成します (例:
request-certificate.yml
)。-
webserver
など、証明書を要求するホストを含むようにhosts
を設定します。 certificate_requests
変数を設定して以下を追加します。-
name
パラメーターを希望する証明書の名前 (mycert
など) に設定します。 -
dns
パラメーターをドメインに設定し、証明書に追加します (例:www.example.com
)。 -
principal
パラメーターを設定し、Kerberos プリンシパルを指定します (例:HTTP/www.example.com@EXAMPLE.COM
)。 -
ca
パラメーターをipa
に設定します。
-
roles
の下にrhel-system-roles.certificate
ロールを設定します。以下は、この例の Playbook ファイルです。
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: www.example.com principal: HTTP/www.example.com@EXAMPLE.COM ca: ipa roles: - rhel-system-roles.certificate
-
- ファイルを保存します。
Playbook を実行します。
$ ansible-playbook -i inventory.file request-certificate.yml
関連情報
-
certificate_requests
変数で使用されるパラメーターの詳細と、certificate
システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
8.4. Certificate システムロールを使用して、証明書の発行前または発行後に実行するコマンドの指定
Certificate システムロールを使用すると、Red Hat Ansible Engine を使用して、証明書の発行または更新の前後にコマンドを実行することができます。
以下の例では、管理者が www.example.com
の自己署名証明書を発行または更新する前に httpd
サービスを停止し、後で再起動します。
デフォルトでは、certmonger
は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew
パラメーターを no
に設定すると無効にできます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記certificate
ソリューションをデプロイするシステムに Ansible をインストールする必要はありません。Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの使用」 を参照してください。
手順
オプション:
inventory.file
などのインベントリーファイルを作成します。$ touch inventory.file
インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。
[webserver] server.idm.example.com
Playbook ファイルを作成します (例:
request-certificate.yml
)。-
webserver
など、証明書を要求するホストを含むようにhosts
を設定します。 certificate_requests
変数を設定して以下を追加します。-
name
パラメーターを希望する証明書の名前 (mycert
など) に設定します。 -
dns
パラメーターをドメインに設定し、証明書に追加します (例:www.example.com
)。 -
ca
パラメーターを証明書を発行する際に使用する CA に設定します (例:self-sign
)。 -
この証明書を発行または更新する前に、
run_before
パラメーターを実行するコマンドに設定します (例:systemctl stop httpd.service
)。 -
この証明書を発行または更新した後に、
run_after
パラメーターを実行するコマンドに設定します (例:systemctl start httpd.service
)。
-
roles
の下にrhel-system-roles.certificate
ロールを設定します。以下は、この例の Playbook ファイルです。
--- - hosts: webserver vars: certificate_requests: - name: mycert dns: www.example.com ca: self-sign run_before: systemctl stop httpd.service run_after: systemctl start httpd.service roles: - linux-system-roles.certificate
-
- ファイルを保存します。
Playbook を実行します。
$ ansible-playbook -i inventory.file request-certificate.yml
関連情報
-
certificate_requests
変数で使用されるパラメーターの詳細と、certificate
システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.certificate/README.md
ファイルを参照してください。 -
ansible-playbook
コマンドの詳細は、man ページのansible-playbook(1)
を参照してください。
第9章 RHEL システムロールを使用した kdump の設定
Ansible を使用して kdump を管理するには、RHEL 8 で利用可能な RHEL システムロールの 1 つである kdump
ロールを使用できます。
kdump
を使用すると、システムのメモリー内容を保存する場所を指定して後で分析できます。
RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの概要」 を参照してください。
9.1. kdump
RHEL システムロール
kdump
システムロールを使用すると、複数のシステムに基本的なカーネルダンプパラメーターを設定できます。
9.2. kdump ロールのパラメーター
kdump
RHEL システムロールに使用するパラメーターは以下のとおりです。
ロール変数 | 説明 |
---|---|
kdump_path |
|
関連情報
- man ページの makedumpfile(8) を参照してください。
-
kdump
で使用されるパラメーターの詳細およびkdump
システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.tlog/README.md
ファイルを参照してください。
9.3. RHEL システムロールを使用した kdump の設定
Ansible Playbook を実行して kdump
システムロールを使用し、複数のシステムに基本的なカーネルダンプパラメーターを設定できます。
kdump
ロールは、/etc/kdump.conf
ファイルを置き換えることで、管理対象ホストの kdump 設定全体を置き換えます。また、kdump ロールが適用されると、/etc/sysconfig/kdump
ファイルを置き換えることで、ロール変数で指定されていない場合でも、以前の kdump の設定もすべて置き換えられます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記kdump
ソリューションをデプロイするシステムに Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
kdump
をデプロイするシステムを一覧表示するインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。--- - hosts: kdump-test vars: kdump_path: /var/crash roles: - rhel-system-roles.kdump
オプション: Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
関連情報
- kdump ロール変数の詳細は、/usr/share/doc/rhel-system-roles/kdump ディレクトリーの README.md ファイルまたは README.html ファイルを参照してください。
- 「ロールの適用」 を参照してください。
-
rhel-system-roles
パッケージをインストールし、/usr/share/ansible/roles/rhel-system-roles.kdump/README.html
のドキュメントを参照してください。
第10章 RHEL システムロールを使用したストレージの設定
Ansible を使用して LVM とローカルファイルシステム (FS) を管理するには、RHEL 8 で利用可能な RHEL システムロールの 1 つである storage
ロールを使用できます。
storage role
を使用すると、ディスク上のファイルシステム、複数のマシンにある論理ボリューム、および RHEL 7.7 以降の全バージョンでのファイルシステムの管理を自動化できます。
RHEL システムロールと、その適用方法の詳細は、「RHEL システムロールの概要」 を参照してください。
10.1. storage ロールの概要
storage
ロールは以下を管理できます。
- パーティションが分割されていないディスクのファイルシステム
- 論理ボリュームとファイルシステムを含む完全な LVM ボリュームグループ
storage
ロールを使用すると、次のタスクを実行できます。
- ファイルシステムを作成する
- ファイルシステムを削除する
- ファイルシステムをマウントする
- ファイルシステムをアンマウントする
- LVM ボリュームグループを作成する
- LVM ボリュームグループを削除する
- 論理ボリュームを作成する
- 論理ボリュームを削除する
- RAID ボリュームを作成する
- RAID ボリュームを削除する
- RAID を使用して LVM プールを作成する
- RAID を使用して LVM プールを削除する
10.2. storage システムロールでストレージデバイスを識別するパラメーター
storage
ロールの設定は、以下の変数に記載されているファイルシステム、ボリューム、およびプールにのみ影響します。
storage_volumes
管理対象のパーティションが分割されていない全ディスク上のファイルシステムの一覧
現在、パーティションはサポートされていません。
storage_pools
管理するプールの一覧
現在、サポートされている唯一のプールタイプは LVM です。LVM では、プールはボリュームグループ (VG) を表します。各プールの下には、ロールで管理されるボリュームの一覧があります。LVM では、各ボリュームは、ファイルシステムを持つ論理ボリューム (LV) に対応します。
10.3. RHEL システムロールを使用してブロックデバイスに XFS ファイルシステムの作成
本セクションでは、storage
ロールを使用して、複数のターゲットマシンのブロックデバイスに XFS ファイルシステムを作成する方法を説明します。
前提条件
storage
ロールを使用する Ansible Playbook がある。このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.3.1. ブロックデバイスに XFS ファイルシステムを作成する Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用し、デフォルトパラメーターを使用してブロックデバイスに XFS ファイルシステムを作成します。
storage
ロールは、パーティションが分割されていないディスク全体または論理ボリューム (LV) でのみファイルシステムを作成できます。パーティションにファイルシステムを作成することはできません。
例10.1 /dev/sdb に XFS を作成する Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs roles: - rhel-system-roles.storage
-
現在、ボリューム名 (この例では
barefs
) は任意です。storage
ロールは、disks:
属性に一覧表示されているディスクデバイスでボリュームを特定します。 -
XFS は RHEL 8 のデフォルトファイルシステムであるため、
fs_type: xfs
行を省略することができます。 論理ボリュームにファイルシステムを作成するには、エンクロージングボリュームグループを含む
disks:
属性の下に LVM 設定を指定します。詳細は、「論理ボリュームを管理する Ansible Playbook の例」 を参照してください。LV デバイスへのパスを指定しないでください。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.4. RHEL システムロールを使用したファイルシステムの永続的なマウント
本セクションでは、storage
ロールを使用して、ファイルシステムを永続的にマウントする方法を説明します。
前提条件
storage
ロールを使用する Ansible Playbook がある。このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.4.1. ファイルシステムを永続的にマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールをすぐに適用して、XFS ファイルシステムを永続的にマウントします。
例10.2 /dev/sdb のファイルシステムを /mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data roles: - rhel-system-roles.storage
-
この Playbook では、ファイルシステムが
/etc/fstab
ファイルに追加され、すぐにファイルシステムをマウントします。 -
/dev/sdb
デバイス上のファイルシステム、またはマウントポイントのディレクトリーが存在しない場合は、Playbook により作成されます。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.5. RHEL システムロールを使用したオンラインのブロック破棄の有効化
本セクションでは、storage
ロールを使用してオンラインのブロック破棄を有効にする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.5.1. オンラインのブロック破棄を有効にする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage
ロールを適用して、オンラインのブロック破棄を有効にして XFS ファイルシステムをマウントします。
例10.3 /mnt/data/ でのオンラインのブロック破棄を有効にする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs mount_point: /mnt/data mount_options: discard roles: - rhel-system-roles.storage
関連情報
- この Playbook は、「ファイルシステムを永続的にマウントする Ansible Playbook の例」 で説明されている永続的なマウント例のすべての操作も実行します。
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.6. RHEL システムロールを使用した ext3 ファイルシステムの作成およびマウント
本セクションでは、ディスクで指定したラベルが付いた ext3 ファイルシステムを作成し、storage
ロールを使用してファイルシステムを永続的にマウントする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.6.1. ext3 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext3 ファイルシステムを作成してマウントします。
例10.4 /dev/sdb に Ext3 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext3 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.7. RHEL システムロールを使用した ext4 ファイルシステムの作成およびマウント
本セクションでは、ディスクで指定したラベルが付いた ext4 ファイルシステムを作成し、storage
ロールを使用してファイルシステムを永続的にマウントする方法を説明します。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
このような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.7.1. Ext4 ファイルシステムを作成してマウントする Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、Ext4 ファイルシステムを作成してマウントします。
例10.5 /dev/sdb に Ext4 を作成し、/mnt/data にマウントする Playbook
--- - hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: ext4 fs_label: label-name mount_point: /mnt/data roles: - rhel-system-roles.storage
-
Playbook は、
/dev/sdb
ディスクにファイルシステムを作成します。 -
Playbook は、
/mnt/data
ディレクトリーにファイルシステムを永続的にマウントします。 -
ファイルシステムのラベルは
label-name
です。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.8. RHEL システムロールを使用した LVM 論理ボリュームの管理
本セクションでは、storage
ロールを適用して次のタスクを実行する方法を説明します。
- 複数のディスクで構成されるボリュームグループに LVM 論理ボリュームを作成します。
- 論理ボリューム上に特定のラベルを付けて ext4 ファイルシステムを作成します。
- ext4 ファイルシステムを永続的にマウントします。
前提条件
-
storage
ロールを含む Ansible Playbook がある。
そのような Playbook を適用する方法は、「ロールの適用」 を参照してください。
10.8.1. 論理ボリュームを管理する Ansible Playbook の例
本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage
ロールを適用して、ボリュームグループに LVM 論理ボリュームを作成します。
例10.6 myvg ボリュームグループに mylv 論理ボリュームを作成する Playbook
- hosts: all vars: storage_pools: - name: myvg disks: - sda - sdb - sdc volumes: - name: mylv size: 2G fs_type: ext4 mount_point: /mnt roles: - rhel-system-roles.storage
myvg
ボリュームグループは、次のディスクで構成されます。-
/dev/sda
-
/dev/sdb
-
/dev/sdc
-
-
myvg
ボリュームグループがすでに存在する場合は、Playbook により論理ボリュームがボリュームグループに追加されます。 -
myvg
ボリュームグループが存在しない場合は、Playbook により作成されます。 -
Playbook は、
mylv
論理ボリューム上に Ext4 ファイルシステムを作成し、/mnt
ファイルシステムを永続的にマウントします。
関連情報
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.8.2. 関連情報
-
storage
ロールの詳細は、「RHEL システムロールを使用したローカルストレージの管理」 を参照してください。
10.9. storage システムロールを使用した RAID ボリュームの設定
storage
システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に RAID ボリュームを設定できます。本セクションでは、要件に合わせて RAID ボリュームを設定するために、利用可能なパラメーターを使用して Ansible Playbook を設定する方法を説明します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記storage
ソリューションをデプロイするシステムに、Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
storage
システムロールを使用して、RAID ボリュームをデプロイするシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_safe_mode: false storage_volumes: - name: data type: raid disks: [sdd, sde, sdf, sdg] raid_level: raid0 raid_chunk_size: 32 KiB mount_point: /mnt/data state: present roles: - name: rhel-system-roles.storage
警告特定の状況でデバイス名が変更する場合があります。たとえば、新しいディスクをシステムに追加するときなどです。したがって、データの損失を防ぐために、Playbook で特定のディスク名を使用することは推奨していません。
オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- RAID の詳細は、「RAID の管理」 を参照してください。
-
storage システムロールで使用されるパラメーターの詳細は、
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.10. storage システムロールを使用した LVM pool with RAID の設定
storage
システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に LVM pool with RAID を設定できます。本セクションでは、利用可能なパラメーターを使用して Ansible Playbook を設定し、LVM pool with RAID を設定する方法を説明します。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記storage
ソリューションをデプロイするシステムに、Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
storage
システムロールを使用して、LVM pool with RAID を設定するシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_safe_mode: false storage_pools: - name: my_pool type: lvm disks: [sdh, sdi] raid_level: raid1 volumes: - name: my_pool size: "1 GiB" mount_point: "/mnt/app/shared" fs_type: xfs state: present roles: - name: rhel-system-roles.storage
注記LVM pool with RAID を作成するには、
raid_level
パラメーターを使用して RAID タイプを指定する必要があります。オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- RAID の詳細は、「RAID の管理」 を参照してください。
-
storage システムロールで使用されるパラメーターの詳細は、
/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
10.11. RHEL システムロールを使用した LUKS 暗号化ボリュームの管理
storage
システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL の Linux Unified Key Setup-on-disk-format (LUKS) で暗号化されたボリュームを管理できます。
10.11.1. storage ロールを使用した LUKS 暗号化ボリュームの作成
storage
ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記ボリュームを作成するシステムに Red Hat Ansible Automation Platform をインストールする必要はありません。
-
Ansible コントローラーに
rhel-system-roles
パッケージがインストールされている。 - storage システムロールを使用して、LUKS 暗号化ボリュームをデプロイするシステムの詳細を記録したインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。- hosts: all vars: storage_volumes: - name: barefs type: disk disks: - sdb fs_type: xfs fs_label: label-name mount_point: /mnt/data encryption: true encryption_password: your-password roles: - rhel-system-roles.storage
オプション:Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
関連情報
- LUKS の詳細は、 17 を参照してください。LUKS を使用したブロックデバイスの暗号化
-
storage
システムロールで使用されるパラメーターの詳細は、/usr/share/ansible/roles/rhel-system-roles.storage/README.md
ファイルを参照してください。
関連情報
詳細は、rhel-system-roles
パッケージをインストールして、/usr/share/doc/rhel-system-roles/storage/
ディレクトリーおよび /usr/share/ansible/roles/rhel-system-roles.storage/
ディレクトリーを参照してください。
第11章 RHEL システムロールを使用した時刻同期の設定
timesync
RHEL システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL の複数のターゲットマシンで時刻同期を管理できます。
11.1. timesync システムロール
timesync
RHEL システムロールを使用して、複数のターゲットマシンで時刻同期を管理できます。
システムクロックが NTP サーバーまたは PTP ドメインのグランドマスターに同期するように、timesync
ロールが NTP 実装または PTP 実装をインストールし、NTP クライアントまたは PTP レプリカとして動作するように設定します。
timesync
ロールを使用すると、システムが ntp
または chrony
を使用して NTP プロトコルを実装するかどうかにかかわらず、RHEL 6 以降のすべてのバージョンの Red Hat Enterprise Linux で同じ Playbook を使用できるため、chrony への移行 が容易になります。
11.2. サーバーの 1 つのプールへの timesync システムロールの適用
以下の例は、サーバーにプールが 1 つしかない場合に、timesync
ロールを適用する方法を示しています。
timesync
ロールは、管理対象ホストで指定または検出されたプロバイダーサービスの設定を置き換えます。以前の設定は、ロール変数で指定されていなくても失われます。timesync_ntp_provider
変数が定義されていない場合は、プロバイダーの唯一の設定が適用されます。
前提条件
Playbook を実行するシステムに Red Hat Ansible Engine がインストールされている。
注記timesync
ソリューションをデプロイするシステムに Red Hat Ansible Automation Platform をインストールする必要はありません。-
Playbook を実行するシステムに
rhel-system-roles
パッケージがインストールされている。 -
timesync
システムロールをデプロイするシステムを一覧表示するインベントリーファイルがある。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: 2.rhel.pool.ntp.org pool: yes iburst: yes roles: - rhel-system-roles.timesync
オプション: Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i inventory_file /path/to/file/playbook.yml
11.3. Timesync
システムロール変数
以下の変数を timesync
ロールに渡すことができます。
-
timesync_ntp_servers
:
ロール変数の設定 | 説明 |
---|---|
hostname: host.example.com | サーバーのホスト名またはアドレス。 |
minpoll: number | 最小ポーリング間隔。デフォルト: 6 |
maxpoll: number | 最大ポーリングの間隔。デフォルト: 10 |
iburst: yes | 高速な初期同期を有効にするフラグ。デフォルト: no |
pool: yes | ホスト名の解決された各アドレスが別の NTP サーバーであることを示すフラグ。デフォルト: no |
関連情報
-
timesync ロール変数の詳細は、rhel-system-roles パッケージをインストールし、
/usr/share/doc/rhel-system-roles/timesync
ディレクトリーの README.md ファイルまたは README.html ファイルを参照してください。
第12章 RHEL システムロールを使用したパフォーマンスの監視
12.1. メトリックシステムロールの概要
RHEL システムロールは、複数の RHEL システムをリモートで管理する一貫した構成インターフェースを提供する Ansible ロールおよびモジュールの集合です。メトリックシステムロールはローカルシステムのパフォーマンス分析サービスを設定します。これには、オプションでローカルシステムによって監視されるリモートシステムの一覧が含まれます。メトリックシステムロールを使用すると、pcp
の設定とデプロイメントが Playbook によって処理されるため、pcp
を個別に設定せずに、pcp
を使用してシステムパフォーマンスを監視できます。
表12.1 メトリックシステムロール変数
ロール変数 | 説明 | 使用例 |
---|---|---|
metrics_monitored_hosts |
ターゲットホストが分析するリモートホストの一覧。これらのホストにはターゲットホストにメトリックが記録されるため、各ホストの |
|
metrics_retention_days | 削除前のパフォーマンスデータの保持日数を設定します。 |
|
metrics_graph_service |
|
|
metrics_query_service |
|
|
metrics_provider |
メトリックを提供するために使用するメトリックコレクターを指定します。現在、サポートされている唯一のメトリックプロバイダーは |
|
関連情報
-
metrics_connections
で使用されるパラメーターの詳細と、メトリックシステムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.metrics/README.md
ファイルを参照してください。
12.2. メトリックシステムロールを使用した視覚化によるローカルシステムの監視
この手順では、メトリック RHEL システムロールを使用してローカルシステムを監視し、grafana
でデータ視覚化を同時にプロビジョニングする方法を説明します。
前提条件
- 監視するマシンに Red Hat Ansible Engine がインストールされている。
-
監視するマシンに
rhel-system-roles
パッケージがインストールされている。
手順
以下のコンテンツをインベントリーに追加して、
/etc/ansible/hosts
Ansible インベントリーのlocalhost
を設定します。localhost ansible_connection=local
以下の内容を含む Ansible Playbook を作成します。
--- - hosts: localhost vars: metrics_graph_service: yes roles: - rhel-system-roles.metrics
Ansible Playbook の実行:
# ansible-playbook name_of_your_playbook.yml
注記metrics_graph_service
ブール値はvalue="yes" に設定されているため、grafana
は自動的にインストールされ、データソースとしてpcp
が追加されてプロビジョニングされます。-
マシンで収集されるメトリックを視覚化するには、「Grafana Web UI へのアクセス」 の説明どおりに
grafana
Web インターフェースにアクセスします。
12.3. メトリックシステムロールを使用した自己監視のための個別システムの集合の設定
この手順では、メトリックシステムロールを使用して、それ自体を監視するマシンの集合の設定方法を説明します。
前提条件
- Playbook を実行するのに使用するマシンに Red Hat Ansible Engine がインストールされている。
-
Playbook の実行に使用するマシンに
rhel-system-roles
パッケージがインストールされている。
手順
Playbook 経由で監視するマシンの名前または IP を、括弧で囲まれた識別グループ名で
/etc/ansible/hosts
Ansible インベントリーファイルに追加します。[remotes] webserver.example.com database.example.com
以下の内容を含む Ansible Playbook を作成します。
--- - hosts: remotes vars: metrics_retention_days: 0 roles: - rhel-system-roles.metrics
Ansible Playbook の実行:
# ansible-playbook name_of_your_playbook.yml
12.4. メトリックシステムロールを使用したローカルマシンを介したマシンの集合の一元監視
この手順では、grafana
を介したデータの視覚化のプロビジョニングおよび redis
経由でのデータのクエリーをしながら、メトリックシステムロールを使用して、マシンの集合を一元管理するローカルマシンの設定方法を説明します。
前提条件
- Playbook を実行するのに使用するマシンに Red Hat Ansible Engine がインストールされている。
-
Playbook の実行に使用するマシンに
rhel-system-roles
パッケージがインストールされている。
手順
以下の内容を含む Ansible Playbook を作成します。
--- - hosts: localhost vars: metrics_graph_service: yes metrics_query_service: yes metrics_retention_days: 10 metrics_monitored_hosts: ["database.example.com", "webserver.example.com"] roles: - rhel-system-roles.metrics
Ansible Playbook の実行:
# ansible-playbook name_of_your_playbook.yml
注記metrics_graph_service
およびmetrics_query_service
のブール値は value="yes" に設定されているため、grafana
は、redis
にインデックス化されたpcp
データの記録のあるデータソースとして追加されたpcp
で自動的にインストールおよびプロビジョニングされます。これにより、pcp
クエリー言語をデータの複雑なクエリーに使用できます。-
マシンによって一元的に収集されるメトリックのグラフィック表示とデータのクエリーを行うには、「Grafana Web UI へのアクセス」 で説明されているように、
grafana
Web インターフェースにアクセスします。
第13章 tlog RHEL システムロールを使用したセッションの録画用のシステムの設定
tlog
RHEL システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL で端末セッションを録画するようにシステムを設定できます。
13.1. tlog システムロール
tlog
RHEL システムロールを使用して、RHEL での端末セッションの録画用に RHEL システムを設定できます。tlog
パッケージおよび関連する Web コンソールセッションプレーヤーを使用すると、ユーザーの端末セッションを録画および再生できます。
SSSD
サービスを介して、ユーザーごと、またはユーザーグループごとに録画を行うように設定できます。端末の入出力はすべて収集され、テキスト形式でシステムジャーナルに保存されます。
関連情報
- RHEL でのセッションの録画に関する詳細は、『セッションの録画』 を参照してください。
13.2. tlog システムロールのコンポーネントおよびパラメーター
セッション録画ソリューションは、以下のコンポーネントで構成されています。
- tlog ユーティリティー
- System Security Services Daemon (SSSD)
- オプション: Web コンソールインターフェース
tlog RHEL システムロールに使用されるパラメーターは以下のとおりです。
ロール変数 | 説明 |
---|---|
tlog_use_sssd (default: yes) | SSSD を使用してセッションの録画を設定します (録画したユーザーまたはグループの管理方法として推奨)。 |
tlog_scope_sssd (default: none) | SSSD 録画スコープの設定: all / some / none |
tlog_users_sssd (default: []) | 録画するユーザーの YAML リスト |
tlog_groups_sssd (default: []) | 録画するグループの YAML リスト |
-
tlog
で使用されるパラメーターの詳細と、tlog システムロールに関する追加情報は、/usr/share/ansible/roles/rhel-system-roles.tlog/README.md
ファイルを参照してください。
13.3. tlog RHEL システムロールのデプロイ
以下の手順に従って、Ansible Playbook を準備して適用し、RHEL システムが systemd ジャーナルに録画データを記録するように設定します。
前提条件
-
コントロールノードから
tlog
システムロールが設定されるターゲットシステムへアクセスするための SSH キーを設定している。 - Ansible Engine が他のシステムを設定するシステムである 1 つのコントロールノードがある。
- Playbook を実行するコントロールノードに Red Hat Ansible Engine がインストールされている。
-
Playbook を実行するコントロールノードに
rhel-system-roles
パッケージがインストールされている。 -
tlog
システムロールを設定するシステムが 1 つ以上ある。tlog
ソリューションをデプロイするシステムに、Red Hat Ansible Automation Platform をインストールする必要はありません。
手順
以下の内容を含む新しい
playbook.yml
ファイルを作成します。--- - name: Deploy session recording hosts: all vars: tlog_scope_sssd: some tlog_users_sssd: - recordeduser roles: - rhel-system-roles.tlog
詳細は以下のようになります。
tlog_scope_sssd
:-
some
は、all
またはnone
ではなく、特定のユーザーおよびグループのみを録画することを指定します。
-
tlog_users_sssd
:-
recordeduser
は、セッションを録画するユーザーを指定します。ただし、ユーザーは追加されない点に留意してください。ユーザーを独自に設定する必要があります。
-
オプション: Playbook の構文を確認します。
# ansible-playbook --syntax-check playbook.yml
インベントリーファイルで Playbook を実行します。
# ansible-playbook -i IP_Address /path/to/file/playbook.yml -v
これにより、Playbook は指定したシステムに tlog
ロールをインストールします。また、定義したユーザーおよびグループで使用できる SSSD 設定ドロップファイルを作成します。SSSD は、これらのユーザーおよびグループを解析して読み取り、シェルユーザーとして tlog
セッションをオーバーレイします。さらに、cockpit
パッケージがシステムにインストールされている場合、Playbook は cockpit-session-recording
パッケージもインストールします。これは、Web コンソールインターフェースで録画を表示および再生できるようにする Cockpit
モジュールです。
検証手順
システムで SSSD 設定ドロップファイルが作成されることを確認するには、以下の手順を実行します。
SSSD 設定ドロップファイルが作成されるフォルダーに移動します。
# cd /etc/sssd/conf.d
ファイルの内容を確認します。
# cat /etc/sssd/conf.d/sssd-session-recording.conf
Playbook に設定したパラメーターがファイルに含まれていることが確認できます。
13.4. CLI でデプロイされた tlog システムロールを使用したセッションの録画
指定したシステムに tlog
システムロールをデプロイしたら、コマンドラインインターフェース (CLI) を使用してユーザー端末セッションを録画できます。
前提条件
-
ターゲットシステムに
tlog
システムロールをデプロイしている。 -
/etc/sssd/conf.d
ファイルに SSSD 設定ドロップファイルが作成されている。
手順
ユーザーを作成し、このユーザーにパスワードを割り当てます。
# useradd recordeduser # passwd recordeduser
上記で作成したユーザーとしてシステムにログインし直します。
# ssh recordeduser@localhost
- 認証用に yes または no を入力するようにシステムが求めたら、「yes」を入力します。
録画したユーザー のパスワードを挿入します。
システムは、セッションを録画していることを示すメッセージを表示します。
ATTENTION! Your session is being recorded!
セッションの録画が完了したら、以下を入力します。
# exit
システムはユーザーからログアウトし、ローカルホストとの接続を閉じます。
これにより、ユーザーセッションは録画および保存され、ジャーナルを使用して再生することができます。
検証手順
ジャーナルで録画したセッションを表示するには、以下の手順を実施します。
以下のコマンドを実行します。
# journalctl -o verbose -r
-
録画したジャーナルエントリー
tlog-rec
のMESSAGE
フィールドを検索します。
13.5. CLI を使用した録画したセッションの表示
コマンドラインインターフェース (CLI) を使用して、ジャーナルからユーザーセッションの録画を再生できます。
前提条件
- ユーザーセッションを録画している。「CLI でデプロイされた tlog システムロールを使用したセッションの録画」 を参照してください。
手順
CLI 端末で、ユーザーセッションの録画を再生します。
# journalctl -o verbose -r
tlog
録画を検索します。$ /tlog-rec
以下のような詳細が表示されます。
- ユーザーセッションの録画用のユーザー名
-
out_txt
フィールド (録画したセッションの raw 出力エンコード) - 識別子番号 TLOG_REC=ID_number
- 識別子番号 TLOG_REC=ID_number をコピーします。
識別子番号 TLOG_REC=ID_number を使用して録画を再生します。
# tlog-play -r journal -M TLOG_REC=ID_number
これにより、ユーザーセッションの録画端末の出力が再生されることがわかります。
法律上の通知
このページには機械翻訳が使用されている場合があります (詳細はこちら)。