フェーズ2まとめ演習 横断課題と初動コマンド集

Linuxエンジニア養成講座 第15回｜全36回・フェーズ2「Linux基礎」の最終回（12/12回目）です。
前回までに学んだこと: 環境変数（PATH, HOME, LANG）の役割、.bashrc と .bash_profile の違い、シェルスクリプトの基本（変数・条件分岐・ループ）（第14回）。
今回学ぶこと: フェーズ2で学んだ全知識を組み合わせた横断課題と、障害対応の初動コマンド集。

この記事を読み終えると、以下のことができるようになります。

• ユーザー作成、ディレクトリ作成、パーミッション設定、サービス確認を一連の作業として実行できる
• 手動で行った確認作業をシェルスクリプトで自動化できる
• 障害発生時に最初に叩くべきコマンドを知っている

alma-mainにSSH接続した状態で進めます。以降のコマンドはすべてalma-main上で実行します。

フェーズ2で学んだこと（振り返り）

前回のシェルスクリプト入門で、フェーズ2「Linux基礎」の個別テーマはすべて終わりました。今回は総仕上げです。まず、ここまで何を学んできたか振り返ります。

これらの知識を個別に使えるだけでは、現場では足りません。実務では「ユーザーを作って、ディレクトリを準備して、パーミッションを設定して、動作確認をする」といった一連の作業を、ミスなく順番通りに進める力が求められます。今回の横断課題で、その流れを体験します。

横断課題 — 「新メンバーの受け入れ準備」

シナリオはこうです。あなたの部署に新しいメンバーが来週配属されることになりました。先輩から「このサーバーに新メンバー用の環境を準備しておいて」と頼まれました。具体的には、ユーザーアカウントの作成、プロジェクト用ディレクトリの準備、パーミッションの設定、サービスの稼働確認、結果のレポート出力を行います。

1つずつ進めていきます。

ステップ0: 作業記録の開始

第2回で学んだ通り、作業を始める前にまず記録を取ります。「作業記録を残してから作業を始める」は現場の基本です。

alma-mainで実行

実行コマンド:

$ script ~/phase2_exercise.log

これで、以降のすべての操作がファイルに記録されます。作業が完了したら exit で記録を終了します。

ステップ1: ユーザー作成（第10回の復習）

新メンバー用のユーザーアカウントを作成します。第10回で学んだ useradd と passwd を使います。

まず、project-user というユーザーを作成します。

実行コマンド:

$ sudo useradd project-user

実行結果:

（出力なし）

次に、パスワードを設定します。passwd コマンドを実行すると対話形式でパスワードの入力を求められます。

実行コマンド:

$ sudo passwd project-user

実行結果:

ユーザー project-user のパスワードを変更。
新しいパスワード:
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。

パスワードは入力しても画面には表示されません。2回同じパスワードを入力してください。演習用なので覚えやすいもので構いません。

続いて、プロジェクト用のグループを作成し、project-user を所属させます。

実行コマンド:

$ sudo groupadd project-team

実行結果:

（出力なし）

実行コマンド:

$ sudo usermod -aG project-team project-user

実行結果:

（出力なし）

usermod -aG の -a は「追加（append）」、-G は「補助グループ」を意味します。-a を付け忘れると、既存の補助グループから外れてしまうので注意してください（第10回で学んだ内容です）。

確認します。

実行コマンド:

$ id project-user

実行結果:

uid=1001(project-user) gid=1001(project-user) groups=1001(project-user),1002(project-team)

project-team グループ（gid=1002）に所属していることが確認できました。お使いの環境ではUID/GIDの数値が異なる場合がありますが、グループ名が正しければ問題ありません。

実行コマンド:

$ grep project-user /etc/passwd

実行結果:

project-user:x:1001:1001::/home/project-user:/bin/bash

実行コマンド:

$ grep project-team /etc/group

実行結果:

project-team:x:1002:project-user

/etc/passwd と /etc/group の両方で、ユーザーとグループが正しく作成されていることを確認できました。

ステップ2: ディレクトリ作成（第6回・第7回の復習）

プロジェクト用のディレクトリを作成します。第7回で学んだ mkdir -p を使えば、親ディレクトリも含めて一度に作成できます。

実行コマンド:

$ sudo mkdir -p /opt/project/{docs,logs,scripts,config}

実行結果:

（出力なし）

{docs,logs,scripts,config} はブレース展開というbashの機能で、4つのディレクトリを一度に指定しています。第7回で学んだ内容の応用です。

tree コマンドで確認します。tree がインストールされていない場合は sudo dnf install -y tree で導入してください（第7回で導入済みの前提です）。

実行コマンド:

$ tree /opt/project/

実行結果:

/opt/project/
├── config
├── docs
├── logs
└── scripts

4 directories, 0 files

4つのサブディレクトリが作成されました。現時点ではすべて root 所有です。次のステップで所有権とパーミッションを設定します。

ステップ3: パーミッション設定（第11回の復習）

第11回で学んだ chown と chmod を使って、所有権とパーミッションを設定します。まず、/opt/project/ 全体の所有者を project-user、所有グループを project-team に変更します。

実行コマンド:

$ sudo chown -R project-user:project-team /opt/project/

実行結果:

（出力なし）

-R は再帰的に（ディレクトリの中身すべてに）適用するオプションです。

次に、ディレクトリごとにパーミッションを設定します。用途に応じて権限を変えるのが現場での基本です。

• /opt/project/ — 770（グループメンバーは読み書き実行可、その他はアクセス不可）
• /opt/project/scripts/ — 750（スクリプトは所有者のみ書き込み可）
• /opt/project/logs/ — 770（ログは書き込み可）
• /opt/project/config/ — 750（設定ファイルは所有者のみ書き込み可）
• /opt/project/docs/ — 750（ドキュメントは所有者のみ書き込み可）

実行コマンド:

$ sudo chmod 770 /opt/project/
$ sudo chmod 750 /opt/project/scripts/
$ sudo chmod 770 /opt/project/logs/
$ sudo chmod 750 /opt/project/config/
$ sudo chmod 750 /opt/project/docs/

実行結果:

（すべて出力なし）

ls -la で確認します。developer ユーザーは project-team グループに属していないため、sudo を付けて実行します。

実行コマンド:

$ sudo ls -la /opt/project/

実行結果:

合計 0
drwxrwx---. 6 project-user project-team 59  3月 31 03:43 .
drwxr-xr-x. 3 root         root         21  3月 31 03:43 ..
drwxr-x---. 2 project-user project-team  6  3月 31 03:43 config
drwxr-x---. 2 project-user project-team  6  3月 31 03:43 docs
drwxrwx---. 2 project-user project-team  6  3月 31 03:43 logs
drwxr-x---. 2 project-user project-team  6  3月 31 03:43 scripts

パーミッションを読み解いてみます。第11回で学んだ rwx の見方です。

• drwxrwx---（/opt/project/ と logs）— 所有者とグループに読み書き実行権限、その他はアクセス不可
• drwxr-x---（config, docs, scripts）— 所有者は読み書き実行可、グループは読みと実行のみ、その他はアクセス不可

補足: 第11回で「SGID」という特殊なパーミッションの概念を紹介しました。SGID をディレクトリに設定すると、その中に作成されるファイルのグループが自動的に親ディレクトリのグループを継承します。実務の共有ディレクトリでは有用な機能ですが、今回はフェーズ2の復習として chmod の基本（オクタル表記の3桁）に留めます。

ステップ4: 設定ファイル作成（第9回の復習）

第9回で学んだ vi を使って、設定ファイルを作成します。

実行コマンド:

$ sudo vi /opt/project/config/app.conf

vi が開いたら、i キーでINSERTモードに入り、以下の内容を入力します。

# Project Configuration
APP_NAME=myproject
APP_PORT=8080
LOG_DIR=/opt/project/logs
LOG_LEVEL=info

入力が終わったら、Escキーを押してノーマルモードに戻り、:wq で保存して終了します。

ファイルの内容を確認します。

実行コマンド:

$ sudo cat /opt/project/config/app.conf

実行結果:

# Project Configuration
APP_NAME=myproject
APP_PORT=8080
LOG_DIR=/opt/project/logs
LOG_LEVEL=info

設定ファイルの所有権とパーミッションを設定します。設定ファイルには機密情報（データベースのパスワード等）が含まれることがあるため、「その他」のアクセスを禁止するのが基本です。

実行コマンド:

$ sudo chown project-user:project-team /opt/project/config/app.conf
$ sudo chmod 640 /opt/project/config/app.conf

実行結果:

（出力なし）

確認します。

実行コマンド:

$ sudo ls -l /opt/project/config/app.conf

実行結果:

-rw-r-----. 1 project-user project-team 98  3月 31 03:44 /opt/project/config/app.conf

-rw-r----- は 640 です。所有者は読み書き可、グループは読み取りのみ、その他はアクセス不可です。

ステップ5: サービス起動確認（第13回の復習）

サーバーの受け入れ準備として、重要なサービスが稼働しているか確認します。第13回で学んだ systemctl is-active と systemctl is-enabled を使います。

まず、サービスが動いている（active）かどうかの確認です。

実行コマンド:

$ systemctl is-active sshd

実行結果:

active

実行コマンド:

$ systemctl is-active crond

実行結果:

active

実行コマンド:

$ systemctl is-active firewalld

実行結果:

active

次に、OS起動時に自動起動する設定（enabled）になっているか確認します。

実行コマンド:

$ systemctl is-enabled sshd

実行結果:

enabled

実行コマンド:

$ systemctl is-enabled crond

実行結果:

enabled

実行コマンド:

$ systemctl is-enabled firewalld

実行結果:

enabled

3つのサービスとも active（動作中）かつ enabled（自動起動有効）であることが確認できました。

ステップ6: 結果をファイルに出力（第8回の復習）

ここまでの確認結果を1つのファイルにまとめます。第8回で学んだリダイレクト（> と >>）を使います。> はファイルを新規作成（上書き）、>> はファイルの末尾に追記です。

実行コマンド:

$ echo "=== System Report ===" > /tmp/system_report.txt
$ echo "Date: $(date '+%Y-%m-%d %H:%M:%S')" >> /tmp/system_report.txt
$ echo "" >> /tmp/system_report.txt
$ echo "--- User Info ---" >> /tmp/system_report.txt
$ id project-user >> /tmp/system_report.txt
$ echo "" >> /tmp/system_report.txt
$ echo "--- Directory Structure ---" >> /tmp/system_report.txt
$ sudo ls -la /opt/project/ >> /tmp/system_report.txt
$ echo "" >> /tmp/system_report.txt
$ echo "--- Service Status ---" >> /tmp/system_report.txt
$ for service in sshd crond firewalld; do echo "$service: $(systemctl is-active $service)"; done >> /tmp/system_report.txt

作成したレポートを確認します。

実行コマンド:

$ cat /tmp/system_report.txt

実行結果:

=== System Report ===
Date: 2026-03-31 03:45:18

--- User Info ---
uid=1001(project-user) gid=1001(project-user) groups=1001(project-user),1002(project-team)

--- Directory Structure ---
合計 0
drwxrwx---. 6 project-user project-team 59  3月 31 03:43 .
drwxr-xr-x. 3 root         root         21  3月 31 03:43 ..
drwxr-x---. 2 project-user project-team 22  3月 31 03:44 config
drwxr-x---. 2 project-user project-team  6  3月 31 03:43 docs
drwxrwx---. 2 project-user project-team  6  3月 31 03:43 logs
drwxr-x---. 2 project-user project-team  6  3月 31 03:43 scripts

--- Service Status ---
sshd: active
crond: active
firewalld: active

Date の値は実行日時によって異なります。ユーザー情報、ディレクトリ構造、サービス状態がまとまったレポートが作成できました。現場では、こうした確認結果をファイルに残して報告に使います。

ステップ7: シェルスクリプト化（第14回の復習）

ステップ6の手動操作は正しく動きましたが、毎回同じコマンドを打つのは手間がかかります。第14回で学んだシェルスクリプトにまとめて、自動化しましょう。

vi で以下のスクリプトを作成します。

実行コマンド:

$ vi ~/check_project.sh

以下の内容を入力してください。i でINSERTモード、入力後に Esc → :wq で保存です。

#!/bin/bash
REPORT="/tmp/auto_report.txt"
echo "=== Automated System Report ===" > "$REPORT"
echo "Date: $(date '+%Y-%m-%d %H:%M:%S')" >> "$REPORT"
echo "" >> "$REPORT"

echo "--- User Check ---" >> "$REPORT"
if id project-user > /dev/null 2>&1; then
    echo "[OK] project-user exists" >> "$REPORT"
    id project-user >> "$REPORT"
else
    echo "[NG] project-user does not exist" >> "$REPORT"
fi
echo "" >> "$REPORT"

echo "--- Directory Check ---" >> "$REPORT"
for dir in /opt/project /opt/project/docs /opt/project/logs /opt/project/scripts /opt/project/config; do
    if [ -d "$dir" ]; then
        echo "[OK] $dir exists" >> "$REPORT"
    else
        echo "[NG] $dir does not exist" >> "$REPORT"
    fi
done
echo "" >> "$REPORT"

echo "--- Service Check ---" >> "$REPORT"
for service in sshd crond firewalld; do
    if systemctl is-active "$service" > /dev/null 2>&1; then
        echo "[OK] $service is running" >> "$REPORT"
    else
        echo "[NG] $service is NOT running" >> "$REPORT"
    fi
done
echo "" >> "$REPORT"

echo "--- Config File Check ---" >> "$REPORT"
if [ -f /opt/project/config/app.conf ]; then
    echo "[OK] app.conf exists" >> "$REPORT"
    ls -l /opt/project/config/app.conf >> "$REPORT"
else
    echo "[NG] app.conf does not exist" >> "$REPORT"
fi

cat "$REPORT"

スクリプトの中身を解説します。

• 1行目の #!/bin/bash — シバン。このスクリプトを bash で実行することを宣言（第14回）
• if id project-user > /dev/null 2>&1 — id コマンドの出力を /dev/null に捨てて、終了ステータス（$?）だけで判定（第14回）
• [ -d "$dir" ] — ディレクトリが存在するかの判定。-f はファイル存在判定（第14回）
• for service in sshd crond firewalld — for ループで複数サービスを順にチェック（第14回）
• Config File Check では ls -l の出力でパーミッションを確認しています

実行権限を付与して実行します。/opt/project/ 配下は project-team グループの権限で保護されているため、sudo で実行します。

実行コマンド:

$ chmod +x ~/check_project.sh
$ sudo bash ~/check_project.sh

実行結果:

=== Automated System Report ===
Date: 2026-03-31 03:45:30

--- User Check ---
[OK] project-user exists
uid=1001(project-user) gid=1001(project-user) groups=1001(project-user),1002(project-team)

--- Directory Check ---
[OK] /opt/project exists
[OK] /opt/project/docs exists
[OK] /opt/project/logs exists
[OK] /opt/project/scripts exists
[OK] /opt/project/config exists

--- Service Check ---
[OK] sshd is running
[OK] crond is running
[OK] firewalld is running

--- Config File Check ---
[OK] app.conf exists
-rw-r-----. 1 project-user project-team 98  3月 31 03:44 /opt/project/config/app.conf

すべて [OK] になりました。手動でやると何分もかかる確認作業が、スクリプトなら数秒で完了します。もし [NG] が出た場合は、該当するステップに戻って修正してください。

やらかし体験 — パーミッションを間違えたら

横断課題が無事に完了しました。ここで、1つ「やらかし」を体験しておきます。パーミッションの設定を間違えるとどうなるか、意図的に試してみましょう。

設定ファイルのパーミッションを 000 に変更します（全員アクセス不可）。

実行コマンド:

$ sudo chmod 000 /opt/project/config/app.conf

実行結果:

（出力なし）

この状態で読もうとするとどうなるでしょうか。

実行コマンド:

$ sudo cat /opt/project/config/app.conf

実行結果:

# Project Configuration
APP_NAME=myproject
APP_PORT=8080
LOG_DIR=/opt/project/logs
LOG_LEVEL=info

sudo を付けると root 権限で動くため、パーミッションに関係なく読めてしまいます。では、sudo を外して一般ユーザーとして読むとどうなるか。developer ユーザーは project-team グループに所属していないため、/opt/project/ ディレクトリにアクセスできません。ここでは project-user に切り替えて試してみます。

実行コマンド:

$ sudo su - project-user -c "cat /opt/project/config/app.conf"

実行結果:

cat: /opt/project/config/app.conf: 許可がありません

「許可がありません」と表示されました。パーミッション 000 のため、ファイルの所有者であっても読めません。

原因を特定するには、ls -l でパーミッションを確認します。

実行コマンド:

$ sudo ls -l /opt/project/config/app.conf

実行結果:

----------. 1 project-user project-team 98  3月 31 03:44 /opt/project/config/app.conf

---------- は全権限が剥奪されている状態です。これを見れば「パーミッションが原因だ」と即座にわかります。正しいパーミッションに修復します。

実行コマンド:

$ sudo chmod 640 /opt/project/config/app.conf

実行結果:

（出力なし）

修復できたか確認します。

実行コマンド:

$ sudo su - project-user -c "cat /opt/project/config/app.conf"

実行結果:

# Project Configuration
APP_NAME=myproject
APP_PORT=8080
LOG_DIR=/opt/project/logs
LOG_LEVEL=info

正常に読めるようになりました。「アクセスできない」と言われたらまず ls -l でパーミッションを確認する。これは現場で毎日使う切り分けの基本です。

ヒヤリハット — 検証用ユーザーを消し忘れた話

演習のクリーンアップ

演習で作成したユーザー、グループ、ディレクトリ、一時ファイルを削除します。上のヒヤリハットで学んだ通り、クリーンアップまでが作業です。

実行コマンド:

$ sudo userdel -r project-user

実行結果:

（出力なし）

実行コマンド:

$ sudo groupdel project-team

実行結果:

（出力なし）

実行コマンド:

$ sudo rm -rf /opt/project/

実行結果:

（出力なし）

一時ファイルも削除します。/tmp/auto_report.txt は sudo bash で作成したため root 所有です。sudo rm -f で削除する必要があります。

実行コマンド:

$ rm -f /tmp/system_report.txt
$ sudo rm -f /tmp/auto_report.txt
$ rm -f ~/check_project.sh

実行結果:

（出力なし）

削除できたか確認します。

実行コマンド:

$ id project-user

実行結果:

id: `project-user': no such user

ユーザーが削除されていることを確認できました。ステップ0で script コマンドを開始しているので、exit と入力して記録を終了します。記録ファイルが不要であれば rm -f ~/phase2_exercise.log で削除してください。

初動コマンド集 — 障害時に最初に叩くコマンド

フェーズ2の最後に、もう1つ大事なものをお渡しします。現場で障害が発生したときに「最初に何を叩けばいいか」をまとめた初動コマンド集です。

障害対応では、まず「サーバーの状態を素早く把握する」ことが求められます。確認すべきリソースは大きく4つに分類できます。

• CPU — 処理が遅い、応答がない
• メモリ — プロセスが異常終了する、OOM Killer が動く
• ディスク — 書き込みができない、ログが出力されない
• ネットワーク — 接続できない、タイムアウトする

今回はフェーズ2で学んだ範囲の「CPU・メモリ・ディスク」の3つに絞ります。ネットワーク関連は第16回以降で扱います。

テーブル中の「初出」のコマンドを補足します。

uptime — 稼働時間と負荷を一目で確認

uptime は、サーバーが最後に起動してからの経過時間と、直近の負荷（ロードアベレージ）を表示します。障害対応の最初の1コマンドとして使われることが多いです。

実行コマンド:

$ uptime

実行結果:

 03:45:50 up 2 days, 11:44,  1 user,   load average: 0.00, 0.00, 0.00

出力の見方です。

• up 2 days, 11:44 — サーバーが2日と11時間44分稼働している。予期しない再起動が発生していないか確認できる
• 1 user — 現在ログインしているユーザー数（自分のSSHセッション）
• load average: 0.00, 0.00, 0.00 — 直近1分、5分、15分のシステム負荷。vCPU数（この環境では2）を超えていたら高負荷の兆候

who / w — ログインユーザーの確認

who は現在ログインしているユーザーの一覧を表示します。w は who の詳細版で、各ユーザーが何を実行しているかも表示します。

SSHでログインした状態で実行すると、以下のように自分のセッションが表示されます。

実行コマンド:

$ who

実行結果（SSH接続時の例）:

developer pts/0        2026-03-31 03:40 (192.168.1.100)

実行コマンド:

$ w

実行結果（SSH接続時の例）:

 03:45:56 up 2 days, 11:44,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
developer pts/0     03:40    0.00s  0.01s  0.00s w

障害対応時に「自分以外にも誰かがログインして作業していないか」を確認するために使います。他の人が同時に作業していると、意図しない変更が入る可能性があるためです。

free -h — メモリ使用量の確認

free -h はメモリの使用状況を人間が読みやすい形式（-h: human-readable）で表示します。

実行コマンド:

$ free -h

実行結果:

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       374Mi       3.2Gi       4.0Mi       403Mi       3.3Gi
Swap:          3.9Gi          0B       3.9Gi

見るべきポイントは2つです。

• available（3.2Gi）— 新しいプロセスが使えるメモリの目安。この値が極端に小さい場合はメモリ不足の兆候
• Swap の used（0B）— スワップが大量に使われている場合、物理メモリが不足してディスクに退避している状態

free の値が小さいこと自体は問題ではありません。Linux はメモリを積極的にキャッシュ（buff/cache）に使うため、free が少なくても available が十分にあれば正常です。

これらの初出コマンドも man uptime、man who、man free で詳細を確認できます。コマンドのオプションを忘れたときは man を引く習慣を続けてください。

この初動コマンド集は、第36回のトラブルシューティング総合演習で本格的に使います。今の段階ではすべてを暗記する必要はありません。「障害が起きたらまずこの表を見る」と覚えておいてください。

自走のヒント

今回の横断課題をやってみて、忘れているコマンドやオプションがあったかもしれません。それは当然のことです。

覚えていないコマンドがあったら、該当する回に戻って復習してください。記事末尾のシリーズ一覧から該当する回を参照できます。そして、コマンドの使い方を忘れたときは man コマンド名 や コマンド名 --help で確認する。この「自分で調べる力」が、現場で最も重要なスキルです。

コマンドを暗記する必要はありません。「こういうことをやりたいときに、こういうコマンドがある」ということを知っていれば、あとは man で調べられます。第26回のシェルスクリプト実践でも、今回と同じようにフェーズ3の知識を組み合わせたスクリプトを作成します。繰り返し使うことで、自然と身についていきます。

理解度チェック

フェーズ2全体の知識を確認します。○か×で答えてください。

Q1. usermod -G project-team project-user を実行すると、project-user の既存の補助グループはそのまま残り、project-team が追加される。

Q2. ディレクトリのパーミッションが drwxr-x--- の場合、「その他」のユーザーはこのディレクトリの中に入れない。

Q3. systemctl is-enabled sshd の結果が enabled であれば、sshd は現在動作中である。

Q4. echo "hello" > /tmp/test.txt を2回実行すると、/tmp/test.txt には “hello” が2行書かれている。

Q5. chmod 640 file.txt を設定すると、所有グループのメンバーはこのファイルを読むことはできるが、書き込むことはできない。

Q6. シェルスクリプトの1行目に #!/bin/bash と書くのは、このスクリプトを bash で実行することをOSに伝えるためである。

Q7. uptime の load average が vCPU 数を大きく超えている場合、システムが高負荷状態にある可能性がある。

Q8. free -h の出力で free の値がほぼ 0 であれば、メモリ不足でサーバーに問題が起きている。

答え合わせです。

Q1. × — -G だけでは既存の補助グループが上書きされます。-aG（-a: append を付ける）で追加になります。第10回で扱った注意点です。

Q2. ○ — 「その他」の位置が --- なので、読み取り・書き込み・実行のいずれもできません。ディレクトリに入る（cd する）には実行権限（x）が必要です。第11回で扱った内容です。

Q3. × — is-enabled は「OS起動時に自動起動するか」の設定です。「現在動作しているか」は is-active で確認します。enabled でも手動で停止していれば active ではありません。第13回で扱った内容です。

Q4. × — > は上書きです。2回実行しても “hello” は1行だけです。追記するには >> を使います。第8回で扱った内容です。

Q5. ○ — 640 は「所有者: 読み書き（6=rw-）、グループ: 読み取りのみ（4=r–）、その他: なし（0=—）」です。第11回で扱った内容です。

Q6. ○ — この1行目をシバン（shebang）と呼びます。第14回で扱った内容です。

Q7. ○ — load average はCPUの実行待ちプロセス数の平均です。vCPU数を超えている場合、処理が滞留している可能性があります。

Q8. × — Linux はメモリを積極的にキャッシュ（buff/cache）に使うため、free が小さいこと自体は正常です。available の値が十分にあれば問題ありません。

まとめ

今回はフェーズ2「Linux基礎」の総仕上げとして、以下を実践しました。

• 「新メンバーの受け入れ準備」というシナリオで、ユーザー作成（第10回）→ ディレクトリ作成（第7回）→ パーミッション設定（第11回）→ 設定ファイル作成（第9回）→ サービス確認（第13回）→ 結果出力（第8回）を一連の作業として実行した
• 手動操作をシェルスクリプトにまとめて自動化した（第14回）
• パーミッションの設定ミスを意図的に再現し、原因特定と修復を体験した
• 障害対応の初動コマンド集を手に入れた（uptime, who, w, free -h は今回初出）

これでフェーズ2は完了です。ファイル操作、テキスト処理、vi、ユーザー管理、パーミッション、プロセス管理、systemd、シェルスクリプト。Linux を操作するための基礎体力が身につきました。

PS> Checkpoint-VM -Name "alma-main" -SnapshotName "SP2_phase2-done"

次回の第16回「ネットワーク基礎」から、フェーズ3「ネットワークとインフラ基盤」に入ります。TCP/IP、サブネット、ポート、DNS解決の流れを学び、ip addr や ping で実際の疎通を確認します。これまでは alma-main 1台で完結していましたが、フェーズ3からは複数のVMを使ったネットワーク越しの操作が中心になります。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1回〜第3回）

• 第1回 エンジニアの仕事と学び方
• 第2回 作業記録と報連相
• 第3回 セキュリティ意識の基本

フェーズ2: Linux基礎（第4回〜第15回）

• 第4回 Linuxとは何か＋環境確認
• 第5回 SSH接続とターミナル操作
• 第6回 ファイルシステムとディレクトリ構造
• 第7回 基本コマンド（ファイル操作）
• 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
• 第9回 viエディタ
• 第10回 ユーザーとグループ管理
• 第11回 パーミッションと所有権
• 第12回 プロセス管理
• 第13回 systemd
• 第14回 シェルスクリプト入門
• 第15回 フェーズ2まとめ演習（この記事）

フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）

• 第16回 ネットワーク基礎
• 第17回 ネットワーク設定と疎通確認
• 第18回 企業ネットワークの仕組み
• 第19回 パッケージ管理
• 第20回 ファイアウォール（firewalld）
• 第21回 ボンディング/チーミング
• 第22回 VLAN
• 第23回 ログ管理
• 第24回 cron / systemd timer
• 第25回 ストレージ管理（LVM）
• 第26回 シェルスクリプト実践
• 第27回 SSH応用

フェーズ4: サーバー構築と運用（第28回〜第36回）

• 第28回 SELinux
• 第29回 Webサーバー構築（Apache/Nginx）
• 第30回 データベース基礎（MariaDB）
• 第31回 バックアップと復旧
• 第32回 監視入門
• 第33回 セキュリティ実践
• 第34回 Git基本操作
• 第35回 自動化と構成管理（Ansible）
• 第36回 トラブルシューティング（総合演習・最終回）