こんにちは
10月1日から再び働きはじめるにあたり、ITのカンを失わないように毎日RHELでハンズオンしております。
自分なりにAIからの指示を噛み砕きながらやってますが、忘れっぽいので後で見返せるようにここに残しておきます。

Codexを使って当時のスクショ整理しつつ良い感じに記事を書いてもらってるので、長いし読みづらいかもしれません（泣）

やったこと

RHELサーバの現在の状態を、OS・CPU・メモリ・ディスクから、サービス・ログ・ネットワークまで一通り確認した。

httpdについては、稼働状態や自動起動設定を確認する操作が残っている。当時の入力を見ると、status と enabled を組み合わせた誤った指定も試していた。今回振り返ると、「今動いている」と「OS起動時に自動起動する設定」は別の観点だと整理できる。

今回は、その途中で間違えたコマンドも含めて振り返る。

OSとハードウェア、容量の確認
SSH・httpdの稼働状態と自動起動設定の確認
ログ、ディレクトリ使用量、セキュリティ設定の確認
ユーザー・cron・接続設定、DNSとHTTP応答の確認

環境

当日の画面から確認できた環境は次のとおり。

項目	内容
OS	Red Hat Enterprise Linux 9.8（Plow）
カーネル	5.14.0-687.38.1.el9_8.x86_64
ホスト名	rhel-lab
CPU	Intel Core i5-1145G7、4コア・8スレッド
メモリ	`free -h` の表示で15Gi
操作ユーザー	labuser
IPv4アドレス	192.168.1.7/24
Apacheパッケージ	httpd-2.4.62-13.el9_8.5.x86_64

以下は、撮影時刻に沿って主な操作を並べている。コードブロックは、特記しない限り当日の画面で確認できる入力を記載した。

ハンズオン

1. IPアドレスと経路を確認する

最初に、サーバに付いているアドレスと通信経路を確認した。

ip addr
ip route

ip addr はネットワークインターフェースのアドレス、ip route はIPv4の経路を表示する。

default via 192.168.1.1 がデフォルトゲートウェイで、dev enp0s31f6 が使用するインターフェース。src 192.168.1.7 から、この経路で使う送信元アドレスも読める。

経路は、宛先へどのインターフェースやゲートウェイを使って送るかを決める情報だ。ただし、経路が表示されたことだけでは、実際に相手から応答が返るとは確認できない。

2. OS・CPU・ディスク・メモリを確認する

次に、操作している環境を確認した。

cat /etc/redhat-release
uname -r
hostnamectl
lscpu

cat はファイルの内容を表示する。uname -r の -r はカーネルのリリース情報を表示する指定。hostnamectl ではホスト名やOS情報、lscpu ではCPUの構成を確認した。

この画面の Red Hat Enterprise Linux release 9.8 がOSのバージョンだ。続くカーネル確認では 5.14.0-687.38.1.el9_8.x86_64、CPU情報では4コア・1コアあたり2スレッドという構成が表示された。

容量の確認には、まず次のコマンドを使った。

df -h

df はファイルシステム単位の使用量を表示し、-h はG・Mなどの単位で読みやすくする指定だ。/ の行ではサイズ70G、使用量3.5G、使用率5%だった。どの領域の数字かは、右端のマウント位置と対応させて読む。

次はメモリ。

free -h

free はメモリとSwapの使用状況を表示する。ここでも -h は読みやすい単位にする指定だ。Mem: の total は15Gi、available は14Gi、Swap: の used は0Bだった。

free 列の空き容量と、アプリケーションが利用できるメモリの目安である available は区別して見る。Linuxではメモリの一部をキャッシュにも使うため、単純に「使われている分は全部アプリの使用量」とは読めない。

その後、df -h を再確認してから、マウント設定とファイルシステム種別を見た。

cat /etc/fstab
df -T

fstabはマウント設定を記述するファイルで、今回は内容を確認した。df -T の -T はファイルシステム種別を表示する指定だ。画面では /・/home・/boot がXFS、/boot/efi がvfatだった。

3. SSHの状態を見てから、httpdを確認する

SSHのサービス状態を確認した。

systemctl status sshd

systemctl はsystemdが管理するサービスなどを操作・確認するコマンドで、status は状態の詳細を表示する。

Active: active (running) からSSHサービスが稼働中であることが分かる。Loaded 行にはユニットファイルの場所と enabled も表示されている。

httpdのインストール状況は次で確認した。

rpm -q httpd

rpm の -q はインストール済みパッケージ情報への問い合わせ。結果は httpd-2.4.62-13.el9_8.5.x86_64 だった。これはインストールの確認であって、実行中かどうかは別に見る必要がある。

4. systemctlの入力を振り返り、「今動いている」と「自動起動」を分ける

スクショを振り返ると、状態を確認するサブコマンドの指定を試行錯誤していたことが分かる。以下はエラーになった入力だ。

systemctl status-enabled httpd
systemctl status--enabled httpd
systemctl status =enabled httpd

最初の2つは Unknown command verb。その名前のサブコマンドはない、というエラーだった。

3つ目では =enabled がユニット名として扱われ、該当ユニットが見つからない旨が表示された。一方で、同時に指定したhttpdの状態は表示されている。画面にhttpdの情報が出たからといって、入力全体が正しかったわけではなかった。

次に、自動起動の確認はできた。

systemctl is-enabled httpd

結果は enabled。ただ、そのあとに is-running や running も試して、再びエラーになっている。当時の入力を見ると、「動いているか」と「自動起動するか」を確認する言葉が混ざっていた。

観点	確認方法	当日確認できたこと
現在の状態	`status` の `Active` 欄	httpdは `active (running)`
自動起動の設定	`is-enabled`	httpdは `enabled`

systemdでは、サービスの実行状態と、起動時に呼び出すための設定を別々に管理する。「今動いている」だけでは「次のOS起動時にも自動起動する設定」とは言えない。 なお、enabled は設定の確認であり、次回の起動成功そのものを保証する表示でもない。Red Hatのsystemd管理資料

今回のhttpdには enabled; preset: disabled とも表示されていた。現在の設定は enabled で、preset は既定の有効化方針を示す別の情報だ。

5. journalctlで「過去に何が起きたか」を確認する

次は、サービスの現在の状態に加えてログも見た。

journalctl | grep httpd

journalctl はジャーナルの閲覧、| は前のコマンドの標準出力を次に渡す記号、grep httpd は httpd を含む行の抽出だ。

日時、プロセス名、メッセージを順に読むと、サーバーの完全修飾ドメイン名を決められないという AH00558 の警告と、80番で待ち受ける旨の記録が見える。

この警告だけで「HTTP応答も失敗する」とは判断できない。応答はこのあと、実際にHTTPリクエストを送って確認する。

ログの指定でも間違えた。

journalctl -u -b httpd

-u は対象ユニットを指定するオプションなので、何のログを見るかを続けて指定する必要がある。前回の起動を対象にした入力は次の形になった。

journalctl -u httpd -b -1

-u httpd がユニットの指定、-b -1 が前回起動の指定だ。しかし、この環境では永続ジャーナルが見つからないという表示になった。

さらに、参照できる起動履歴を確認した。

journalctl --list-boots

--list-boots はジャーナルに記録された起動の一覧を表示する。画面にはインデックス0の今回の起動だけが表示された。これは「前回起動で何も起きなかった」ことを意味しない。今回参照できるログからは、前回の内容を確認できなかったということだ。

ジャーナルの保存方法によって、再起動後にもログを参照できるかが変わる。Red Hatのログ確認資料

6. /varの使用量を調べると、権限と並べ替えでつまずいた

ファイルシステム全体の空き容量に続き、/var のどこが容量を使っているかも調べた。

du -h /var

du はファイルやディレクトリが使うディスク領域を集計する。-h は読みやすい単位にする指定だ。しかし、この実行では一部のディレクトリを読めなかった。エラーが出ているため、表示を完全な集計結果としては扱えない。

続いて sudo du -sh /var/* を実行した。sudo は権限を切り替えて実行するためのもので、今回はroot権限での実行。-s は指定した各対象の合計だけを表示する。/var/* はシェルが展開する指定で、通常はドットから始まる名前を含まない。

sudoの認証では一度再入力になったが、その後は各ディレクトリの使用量が表示された。

並べ替えようとして、次の入力でも失敗した。

sudo du -sh /var/* | sort 1

1 が並べ替え方法ではなく、入力ファイル名として扱われていた。

最終的に、大きいものを3件表示できた。

sudo du -sh /var/* | sort -hr | head -3

sort -h はMやGなどの単位を考慮した並べ替え、-r は逆順、head -3 は先頭3行の表示だ。GNU sortの説明

結果は /var/cache が415M、/var/lib が79M、/var/log が11Mだった。

7. サービス全体、firewalld、SELinuxを確認する

失敗状態のユニットと稼働中のサービスを確認した。

systemctl --failed
systemctl list-units --type=service --state=running

--failed は失敗状態に絞る指定。後者は --type=service でサービス、--state=running で実行中のものに絞る。結果は失敗ユニット0件、稼働中サービス24件だった。

ただし、失敗ユニット0件という表示から、アプリケーションの全機能まで正常と断定することはできない。

次に、ファイアウォールの設定を確認した。

sudo firewall-cmd --list-all

--list-all は対象ゾーンの設定一覧を表示する。ゾーン指定を省略したこの実行では、デフォルトゾーンの設定を確認している。画面では public (active)、インターフェースは enp0s31f6、services に http と ssh が含まれていた。firewalldのコマンド資料

この表示は許可設定の確認であり、別端末からの接続成功を示すものではない。

SELinuxについては、最初に selinux と入力してコマンドが見つからないエラーになった。その後、現在のモードを確認できた。

getenforce

結果は Enforcing。SELinuxのポリシーに基づくアクセス制御が適用されるモードだ。firewalldで通信を許可することと、SELinuxによるアクセス制御は別の確認項目になる。Red HatのSELinux入門

8. 時刻・ユーザー・cronを確認する

サーバの時刻設定を確認した。時刻設定は、ログの日時を読む際にも参考になる。

timedatectl

タイムゾーンは Asia/Tokyo、System clock synchronized は yes、NTP service は active。表示時点で同期済みであることを確認した。

id labuser
cat /etc/passwd | grep labuser

id は指定ユーザーのUID・GID・所属グループを表示する。labuser のUIDとGIDは1000、所属グループには wheel と project が表示された。

後者は /etc/passwd の内容から labuser を含む行を抽出するもの。ホームディレクトリは /home/labuser、ログインシェルは /bin/bash と確認できた。

cronについては、次のコマンドを打った。

crontab -e
crontab -l

-e は編集、-l は現在のユーザーの登録内容の表示だ。

9. 接続設定を確認し、DNSとHTTPの応答を見る

最後にNetworkManagerの接続情報を確認した。

nmcli connection show

これは接続プロファイルを一覧表示するコマンドで、画面には enp0s31f6 と lo が表示された。

続く設定の画像には、IPv4の方法が manual、アドレスが 192.168.1.7/24、DNSとゲートウェイが 192.168.1.1 と写っている。ただし、その詳細表示の入力行はない。固定IPをこの日に設定したという記録にはしない。

名前解決は次で確認した。

nslookup google.com

nslookup はDNSへの問い合わせに使う。結果の Server は問い合わせ先の 192.168.1.1、その下には google.com のアドレスが返っていた。ここで確認できるのはDNS応答であって、Webページの取得成功ではない。

最後に、ローカルのApacheへHTTPリクエストを送った。

curl -I http://127.0.0.1

127.0.0.1 は自分自身を指すループバックアドレス。curl の -I はHTTPではHEADリクエストを送り、レスポンスヘッダーを取得する指定だ。curlの公式マニュアル

先頭の HTTP/1.1 200 OK から、このリクエストが成功したと分かる。Server にはApacheの情報、Content-Type には text/html; charset=UTF-8 が表示された。

先ほどログにはApacheの警告があったが、このローカルのHTTP確認では成功している。

ハマったところ

systemctl では、status-enabled などの誤った入力と、is-enabled で結果を確認できた記録が残っている。当時何を考えてその名前を入力したかまでは覚えていないが、実行記録からは複数の指定を試していたことが分かる。ここでは、その結果と今回の振り返りで整理した説明を並べる。

つまずいた点	今回の振り返りで整理したこと
`status-enabled` など、状態確認と自動起動設定の言葉が混ざった入力	`Active` 欄と `is-enabled` は別の観点
journalctlの引数指定	対象ユニットと起動回をそれぞれ指定する
前回起動のログを参照できない	コマンドの形に加えて、参照可能なログの保存状況も関係する
duで一部を読めない	権限エラーがある集計を完全な結果として扱わない
`sort 1`	エラーに出たファイル名から、引数がどう解釈されたかを確認する
`selinux`、`setuid labuser`	この環境ではその入力で実行できず、後に `getenforce`、`id` で確認した

今回理解したこと

今回、実行記録を振り返ると、「コマンドを実行して結果を見る」だけでなく、「何の状態を確認するためのコマンドなのか」を分けて整理できる。

httpdだけでも、確認する情報は分かれている。

確認したいこと	今回の確認方法
インストールされているか	`rpm -q httpd`
現在動いているか	httpdの `Active` 欄
自動起動の設定か	`systemctl is-enabled httpd`
過去に何が起きたか	`journalctl`
実際にHTTP応答が返るか	`curl -I http://127.0.0.1`

今回の振り返りでは、今の状態、起動時の設定、過去の記録、リクエストへの応答は、それぞれ別に見る必要があると整理できる。当時の操作と結果は上の表のとおりで、この整理は記事を書く際に行ったものだ。

まとめ

Day01は、RHELサーバの状態を一通り確認する日になった。

今回の振り返りのポイントは、httpdの active と enabled を分けて考えること。自動起動設定があっても現在の稼働状態は別に確認し、稼働していても実際のHTTP応答はリクエストを送って確かめる。

コマンド名だけを覚えるのではなく、「この出力のどこから、何が分かったのか」まで読むことを、今後のハンズオンでも続けていきたい。