はじめに
この最終ガイド付きラボでは、RHCSA の準備に必要な複数のスキルを統合します。コマンドのガイダンスは提供されますが、各ステップは管理者の検証ワークフローに近い形で行います。つまり、システムを調査し、必要な状態を設定し、標準ツールを使用して最終結果を証明します。
このラボでは、ローカルのオペレーターID の作成、永続ストレージの準備、そのストレージを使用した小規模なサービスのデプロイ、SELinux およびファイアウォールポリシーの追加、そして最終的な準備状況の確認を行います。
準備されたシステムの調査
このステップでは、最終ワークフローのために準備されたリソースを調査します。まずはブロックデバイス、サービスの状態、および SELinux モードを確認することから始めます。
セットアップにより、public ゾーンでは SSH と 3002/tcp を使用する LabEx ブラウザーターミナルへのアクセスが永続的に許可されています。アプリケーションのファイアウォールポリシーを変更する際も、これらの管理用ルールは維持してください。
プロジェクトディレクトリに移動します。
cd /home/labex/project
準備されたパーティションのパスを表示します。後のコマンドでこのパスを再利用するため、どのブロックデバイスがラボのものかを推測する必要はありません。
cat /home/labex/project/rhcsa-final-part
準備されたブロックデバイスを調査します。まだ最終的なファイルシステムは作成されていないため、これがフォーマット前のベースラインとなります。
lsblk "$(cat /home/labex/project/rhcsa-final-part)"
最終サービスがまだ設定されていないことを確認します。|| true を使用することで、現時点でユニットが存在しなくてもラボの進行を止めないようにしています。
systemctl status rhcsa-final-web.service --no-pager || true
作業を開始する前に、SELinux が Enforcing モードであることを確認します。後のステップで行う SELinux ラベルの設定は単なる情報提供ではなく、ポリシーが適用されるかどうかに影響するため、Enforcing モードであることが重要です。
getenforce
オペレーターID と共有ディレクトリの作成
このステップでは、ローカルグループ、ローカルユーザー、および setgid が設定された共有ディレクトリを作成します。コマンドは、再実行が必要な場合でも安全に行えるように記述されています。
グループが存在しない場合は作成します。getent group でまずローカルの名前サービスを確認し、|| 以降のコマンドは検索が失敗した場合にのみグループを作成します。
getent group rhcsaops || sudo groupadd rhcsaops
finaladmin ユーザーが存在しない場合は作成します。
id finaladmin >/dev/null 2>&1 || sudo useradd -m -s /bin/bash -G rhcsaops finaladmin
ユーザーがオペレーターグループのメンバーであることを確認します。-aG オプションは、ユーザーの既存の補助グループを置き換えるのではなく、グループメンバーシップを追加します。
sudo usermod -aG rhcsaops finaladmin
id finaladmin
オペレーターのメモ用に共有ディレクトリを作成します。モード 2770 はグループにフルアクセス権を与え、setgid ビットを設定するため、新規作成されたファイルは rhcsaops グループを継承します。
sudo mkdir -p /srv/rhcsa-final/team
sudo chown root:rhcsaops /srv/rhcsa-final/team
sudo chmod 2770 /srv/rhcsa-final/team
finaladmin としてテストファイルを作成します。
sudo -u finaladmin bash -c 'echo final validation access > /srv/rhcsa-final/team/finaladmin.txt'
ディレクトリとファイルを確認します。
sudo stat -c '%a %U:%G %n' /srv/rhcsa-final/team /srv/rhcsa-final/team/finaladmin.txt
永続ストレージの準備
このステップでは、準備されたパーティション上にファイルシステムを作成し、UUID を使用して永続的にマウントします。これは、RHCSA 形式のタスクで使用されるストレージ検証パターンを模倣しています。
準備されたパーティションのパスをシェル変数に格納します。
part="$(cat /home/labex/project/rhcsa-final-part)"
識別可能なラベルを付けて ext4 ファイルシステムを作成します。これは準備された練習用パーティションを破壊する操作であるため、デバイスパスを確認した後にのみ実行してください。
sudo mkfs.ext4 -F -L RHCSA_FINAL "$part"
マウントポイントを作成します。
sudo mkdir -p /mnt/rhcsa-final
ファイルシステムの UUID を取得し、このマウントポイントに対する古い fstab 行を置き換えます。UUID は永続マウントのための安定した識別子であり、古い行を削除することで fstab の重複エントリを防ぎます。
uuid="$(sudo blkid -s UUID -o value "$part")"
sudo sed -i '/\/mnt\/rhcsa-final/d' /etc/fstab
永続マウントエントリを追加します。
echo "UUID=$uuid /mnt/rhcsa-final ext4 defaults 0 0" | sudo tee -a /etc/fstab
fstab からマウントし、結果を確認します。mount -a は fstab の行が正しく機能していることを証明し、findmnt と df はマウントターゲットと利用可能な容量を確認します。
sudo mount -a
findmnt /mnt/rhcsa-final
df -h /mnt/rhcsa-final
最終サービスのデプロイと有効化
このステップでは、マウントされたファイルシステム上に Web コンテンツを配置し、ポート 18083 でローカルにサービスを提供する systemd サービスを作成します。
Web コンテンツディレクトリを作成します。
sudo mkdir -p /mnt/rhcsa-final/www
コンテンツファイルを作成します。
echo "RHCSA final validation service" | sudo tee /mnt/rhcsa-final/www/index.html >/dev/null
labex サービスユーザーが誰でも書き込める状態にせずにコンテンツを読み取れるよう、権限を設定します。サービスにはグループ読み取り権限とディレクトリトラバーサル権限が必要ですが、広範な書き込み権限は不要です。
sudo chown -R root:labex /mnt/rhcsa-final/www
sudo chmod 750 /mnt/rhcsa-final/www
sudo chmod 640 /mnt/rhcsa-final/www/index.html
サービスユニットを作成します。このサービスはマウントされたコンテンツディレクトリから実行され、18083 ポートの localhost にバインドされるため、curl を使用してローカルで簡単に検証できます。
sudo tee /etc/systemd/system/rhcsa-final-web.service >/dev/null <<'EOF'
[Unit]
Description=RHCSA final validation web service
After=network.target
[Service]
Type=simple
User=labex
Group=labex
WorkingDirectory=/mnt/rhcsa-final/www
ExecStart=/usr/bin/python3 -m http.server 18083 --bind 127.0.0.1
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
ユニットファイルを保護し、systemd をリロードしてサービスを有効化します。/etc/systemd/system 配下のユニットファイルは root 所有であるべきであり、daemon-reload を実行することで、有効化および再起動の前に systemd が新しいユニットを読み込むようになります。
sudo chown root:root /etc/systemd/system/rhcsa-final-web.service
sudo chmod 644 /etc/systemd/system/rhcsa-final-web.service
sudo systemctl daemon-reload
sudo systemctl enable rhcsa-final-web.service
sudo systemctl restart rhcsa-final-web.service
sleep 1
サービスをテストします。
systemctl is-active rhcsa-final-web.service
curl -s http://127.0.0.1:18083/
SELinux およびファイアウォールポリシーの追加
このステップでは、サービスポリシーを完成させます。コンテンツとポートに対して永続的な SELinux ラベルを追加し、firewalld でポートを開放します。
永続的なファイルコンテキストルールを追加または更新します。|| パターンを使用することで、ルールが欠落している場合は追加し、パスに既にカスタムルールがある場合はそれを変更するという安全な再実行が可能になります。
sudo semanage fcontext -a -t httpd_sys_content_t '/mnt/rhcsa-final/www(/.*)?' || sudo semanage fcontext -m -t httpd_sys_content_t '/mnt/rhcsa-final/www(/.*)?'
コンテキストルールを適用します。restorecon は、作成した永続的な SELinux ルールに合わせて現在のファイルラベルを変更します。
sudo restorecon -Rv /mnt/rhcsa-final/www
SELinux の HTTP ポートラベルを追加または更新します。この追加・修正パターンは、クリーンなシステムと、既にポートラベルが存在する再実行時の両方に対応します。
sudo semanage port -a -t http_port_t -p tcp 18083 || sudo semanage port -m -t http_port_t -p tcp 18083
firewalld を起動し、サービスポートを永続的に開放します。
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=18083/tcp
sudo firewall-cmd --reload
ラベルとファイアウォールの状態を調査します。これらのチェックにより、ポリシー設定がファイルラベル、許可された HTTP ポートタイプ、および開放されたファイアウォールポートという観測可能な状態に反映されていることを確認します。
ls -Z /mnt/rhcsa-final/www/index.html
sudo semanage port -l | grep '^http_port_t'
sudo firewall-cmd --list-ports
最終的な準備状況の確認
このステップでは、コース全体で使用してきたツールを使用して、システム全体の状態を検証します。これはレポート作成ではなく、運用上のチェックです。
ローカル ID とグループメンバーシップを確認します。
id finaladmin
getent group rhcsaops
永続ストレージを確認します。ライブマウントと保存された fstab エントリの両方を検証します。どちらか一方だけではストレージ要件の半分しか満たしていないことになるためです。
findmnt /mnt/rhcsa-final
grep /mnt/rhcsa-final /etc/fstab
サービスを確認します。
systemctl is-enabled rhcsa-final-web.service
systemctl is-active rhcsa-final-web.service
curl -s http://127.0.0.1:18083/
SELinux と firewalld を確認します。最終状態として、SELinux が Enforcing であること、サービスファイルに HTTP コンテンツラベルが付与されていること、そして firewalld で 18083/tcp が開放されていることが確認できるはずです。
getenforce
ls -Z /mnt/rhcsa-final/www/index.html
sudo firewall-cmd --list-ports
まとめ
オペレーターID の設定、setgid 共有ディレクトリ、永続ストレージ、systemd サービス、SELinux ファイルおよびポートラベル、firewalld による公開、そしてコマンドベースの最終検証を行うことで、RHCSA に向けた最終的な準備ワークフローを完了しました。
