CLI Exercise Case PackCLI操作演習案件パック

使用する主なコマンド：which、find、ls、less

$ which nginx
/usr/sbin/nginx
$ find /etc -maxdepth 2 -iname "nginx.conf"
/etc/nginx/nginx.conf
$ ls -l /etc/nginx/nginx.conf
-rw-r--r-- 1 root root 1257 Jun 12 09:41 /etc/nginx/nginx.conf
$ less /etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
}

http {
    include /etc/nginx/mime.types;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
(END)

whichの結果は実行ファイルがシステムに存在することを示し、findの結果で設定ファイルの実パスが特定できます。ls -lの権限が-rw-r--r--で所有者がroot（システム全体を操作できる管理者ユーザー）であれば、一般ユーザーは読み取りのみ可能な標準的な状態だと判断できます。lessで開いた内容から、このファイルが個別サイトの設定をincludeで取り込む「入口」の役割であることが読み取れます。

使用する主なコマンド：pwd、ls、cp、diff、stat

$ pwd
/etc/nginx/sites-available
$ ls -l app.conf
-rw-r--r-- 1 root root 842 Aug 20 09:15 app.conf
$ sudo cp -i app.conf app.conf.bak.20260829
$ diff -u app.conf app.conf.bak.20260829
$ stat -c '%A %a %n' app.conf.bak.20260829
-rw-r--r-- 644 app.conf.bak.20260829

ls -lの結果から、対象ファイルが存在し所有者がrootであることを事前に確認できます。/etc/nginx/sites-availableディレクトリへの書き込みには管理者権限が必要なためsudoを付けて実行し、-iオプションにより複製先が既に存在する場合だけ上書き確認が入ります（今回は初回実行のため確認なしでそのまま複製されます）。diff -uは差分がなければ何も出力しないため、出力が空であることが「複製が正しく完成した」証拠になります。最後のstatで権限が複製元と同じ644であることを確認し、バックアップとして問題なく保存できたと判断します。

安全メモ：依頼者に対象ファイルのフルパスを復唱して認識合わせを行い、sudoを使う操作である点を意識したうえでcp -iの上書き確認を必ず有効にしたまま実行します。元に戻す必要が生じた場合はsudo cp app.conf.bak.20260829 app.confで復元できることをあらかじめ確認しておきます。

使用する主なコマンド：uptime、free、ps

$ uptime
 14:32:05 up 12 days,  3:41,  2 users,  load average: 3.85, 3.10, 2.40

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8Gi       5.6Gi       312Mi       102Mi       1.9Gi       1.7Gi
Swap:          2.0Gi       1.2Gi       808Mi

$ ps -eo pid,user,pcpu,pmem,etime,comm --sort=-pcpu | head
    PID USER      %CPU %MEM     ELAPSED COMMAND
   2318 appuser   92.0  8.1       00:47 java
   2110 appuser   15.3  3.2    01:15:02 java
    980 root       2.1  0.4    12-03:41:58 sshd
    511 root       0.8  0.3    12-03:41:55 nginx
      1 root       0.1  0.2    12-03:41:59 systemd

この例では、ロードアベレージが同時利用者数やCPUコア数に対してかなり高い水準になっており、負荷が高い状態と読み取れます。さらにpsの出力を見ると、PID（プロセスに付けられた識別番号）2318のjavaプロセスがCPUを92%使用しています。ELAPSED（起動してからの経過時間）は00:47で、直近に始まったばかりです。この2点から、このプロセスが今回の遅さに関係している可能性が高いと判断できます。free -hの出力ではスワップ（Swap）の使用量が1.2Giとあり、メモリ不足によるスワップも遅延の一因と考えられます。ただしこの時点では原因を断定せず、プロセスの詳細調査や担当者への確認が次の対応になります。

使用する主なコマンド：systemctl、journalctl、ss

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2026-08-29 09:12:03 JST; 5h 20min ago
   Main PID: 1188 (nginx)
      Tasks: 3 (limit: 4915)
     Memory: 5.2M
        CPU: 812ms
     CGroup: /system.slice/nginx.service
             ├─1188 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─1189 nginx: worker process

$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

$ journalctl -u nginx -n 50 --since "30 min ago"
-- No entries --

$ ss -tulnp
Netid  State   Recv-Q Send-Q   Local Address:Port    Peer Address:Port  Process
tcp    LISTEN  0      511         127.0.0.1:80             0.0.0.0:*      users:(("nginx",pid=1188,fd=6))
tcp    LISTEN  0      128           0.0.0.0:22              0.0.0.0:*      users:(("sshd",pid=812,fd=3))

systemctl statusではActive: active (running)と表示されており、サービス自体は起動していることが読み取れます。systemctl --failedでも失敗しているユニットはなく、journalctlの直近30分のログにもエラーは出ていません。一方でss -tulnpの出力を見ると、nginxは127.0.0.1:80、つまりサーバー自身からしかアクセスできないループバックアドレスでしか待ち受けていないことがわかります。サービスは正常でも社内の他の端末からは接続できない状態であり、listenディレクティブ（nginxがどのIPアドレス・ポートで待ち受けるかを指定する設定項目）などの設定を確認してもらう必要がある、という推測につながります。

安全メモ：この案件ではsystemctl status／--failed、journalctl、ssといった参照系コマンドのみを使用し、サービスの停止・再起動・設定変更は行っていません。ログにはアクセス元IPなどの情報が含まれることがあるため、報告や共有の際は取り扱いに注意します。

使用する主なコマンド：nginx -t、systemctl reload、systemctl status、curl

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

$ sudo systemctl reload nginx

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2026-08-29 09:12:03 JST; 5h 41min ago
   Main PID: 1188 (nginx)
      Tasks: 3 (limit: 4915)
     Memory: 5.4M
        CPU: 823ms
     CGroup: /system.slice/nginx.service
             ├─1188 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             └─2450 nginx: worker process

$ curl -I --max-time 5 http://localhost
HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Sat, 29 Aug 2026 05:53:10 GMT
Content-Type: text/html
Content-Length: 615
Connection: keep-alive

sudo nginx -tでsyntax is ok / test is successfulと表示されていれば、設定ファイルに文法上の誤りがないことが確認できます。reload実行後もsystemctl statusのMain PIDが1188のまま、Activeの起動時刻も変わっていないことから、プロセスが再起動されずに無停止で設定が反映されたと読み取れます。最後にcurl -I --max-time 5 http://localhostでHTTP/1.1 200 OKが返っていれば、Webサーバーが正常に応答していることの確認になります。

安全メモ：反映前に必ずsudo nginx -tで構文チェックを行い、エラーが出た場合は絶対にreloadを実行せず担当者に差し戻します。stopではなくreloadを使うことで既存の接続を維持したまま反映でき、影響を最小限にできます。念のため編集前の設定ファイルのバックアップの有無や、異常時に元の設定へ戻す手順を担当者と確認しておくと安全です。

もし構文チェックでエラーが出ていたら：設定ファイルの記述を誤ると、たとえば次のようなエラーが表示されることがあります（架空の例です）。

$ sudo nginx -t
nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/app.conf:12
nginx: configuration file /etc/nginx/nginx.conf test failed

この場合はまだ何も反映されていません。エラー行（この例では12行目）と内容を担当者に伝えて設定ファイルを差し戻すか、依頼者の許可を得て自分でその1行だけを修正し、再度sudo nginx -tでsyntax is ok / test is successfulに変わることを確認してからreloadに進みます。testが失敗したままreloadを実行してはいけません。

使用する主なコマンド：whoami、id、ls、stat、chown、chmod

$ whoami
student01
$ id
uid=1001(student01) gid=1001(student01) groups=1001(student01),1002(app-readers)
$ ls -l /var/log/app/access.log
-rw------- 1 app app 3145728  8月 29 09:12 /var/log/app/access.log
$ stat -c '%A %a %n' /var/log/app/access.log
-rw------- 600 /var/log/app/access.log
$ sudo chown app:app-readers /var/log/app/access.log
$ sudo chmod 640 /var/log/app/access.log
$ ls -l /var/log/app/access.log
-rw-r----- 1 app app-readers 3145728  8月 29 09:12 /var/log/app/access.log

stat の結果から、ファイルの権限が600（所有者のみ読み書き可）になっていることがわかります。つまり、id で確認した app-readers グループに自分が所属していても、そもそもグループには読み取り権限が付与されていなかったのです。chown で所有グループを app-readers に変更し、chmod 640 で「所有者は読み書き、グループは読み取りのみ」に権限を広げたことで、グループメンバーからも参照できる状態にしました。最後の ls -l で所有グループが app-readers、権限が rw-r----- になっていれば、修正が意図通り反映されたと判断できます。

安全メモ：sudo で所有者・権限を変更する前に、対象パスが依頼のあった1ファイルだけであることを ls -l で再確認し、他の設定ファイルやログまで巻き込まないようにします。変更前の stat の出力を控えておくと、想定と違う結果になったときに元の状態へ戻す手がかりになります。

使用する主なコマンド：getent、ip、curl

$ getent hosts partner.example.com
198.51.100.45   partner.example.com
$ ip route
default via 203.0.113.1 dev eth0 proto dhcp metric 100
203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10
$ curl -I --max-time 5 https://partner.example.com
curl: (28) Connection timed out after 5001 milliseconds

getent hosts の結果からIPアドレスへの名前解決はできており、DNSの問題ではないと判断できます。ip route でデフォルトゲートウェイへの経路が設定されていることも確認できたため、社内ネットワークの出口までは問題なさそうです。一方で curl -I の結果はタイムアウトしており、名前解決と経路は正常でも、宛先ポート（443番）まで到達できていないことがわかります。取引先側のファイアウォールや相手サーバーの状態まではこの手順だけでは確認できないため、断定は避け「DNSと経路は正常、ポート到達に問題がある可能性が高い」という段階までを報告します。

使用する主なコマンド：ls、ssh-keygen、ssh-copy-id、ssh

$ ls -la ~/.ssh
drwx------  2 student01 student01 4096  8月 20 10:00 .
drwx------ 15 student01 student01 4096  8月 20 09:55 ..
-rw-------  1 student01 student01  411  8月 20 10:00 id_ed25519
-rw-r--r--  1 student01 student01   98  8月 20 10:00 id_ed25519.pub
$ ssh-keygen -t ed25519 -C "student@example.com" -f ~/.ssh/lab_key
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/student01/.ssh/lab_key
Your public key has been saved in /home/student01/.ssh/lab_key.pub
$ ls -la ~/.ssh
drwx------  2 student01 student01 4096  8月 29 10:05 .
drwx------ 15 student01 student01 4096  8月 20 09:55 ..
-rw-------  1 student01 student01  411  8月 20 10:00 id_ed25519
-rw-r--r--  1 student01 student01   98  8月 20 10:00 id_ed25519.pub
-rw-------  1 student01 student01  411  8月 29 10:05 lab_key
-rw-r--r--  1 student01 student01   98  8月 29 10:05 lab_key.pub
$ ssh -i ~/.ssh/lab_key student@192.0.2.20
The authenticity of host '192.0.2.20 (192.0.2.20)' can't be established.
ED25519 key fingerprint is SHA256:ab12CD34ef56GH78ij90KL12mn34OP56qr78ST90uv.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.0.2.20' (ED25519) to the list of known hosts.
Last login: Fri Aug 28 22:10:03 2026 from 203.0.113.10
student@labsrv2:~$

ls -la ~/.ssh の結果から、ディレクトリ自体が700（所有者のみアクセス可）、新しく作った秘密鍵 lab_key が600（所有者のみ読み書き可）、公開鍵 lab_key.pub が644になっており、鍵認証で推奨される権限になっていることを確認できます。ssh 接続時に表示されたホスト鍵のフィンガープリントは、接続先サーバーの管理者から事前に共有された値と別経路で照合したうえで yes と応答します。プロンプトが student@labsrv2 に変わっていれば、鍵認証でのSSH接続に成功したと判断できます。

安全メモ：初めて接続するホストのフィンガープリントは、SSH接続そのものとは異なる手段（電話や社内の別ドキュメントなど）で確認済みの値と照合してから yes と答えます。秘密鍵ファイルの権限が 600 以外になっていないか、誤って他人に共有・アップロードしていないかを都度確認します。

使用する主なコマンド：df、du、find

$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda1      ext4   50G   47G  1.2G  98% /
$ du -sh /var/log/* | sort -rh | head
3.2G    /var/log/app
1.1G    /var/log/nginx
210M    /var/log/journal
$ find /var/log -type f -name "*.gz" -mtime +30
/var/log/app/access.log.12.gz
/var/log/app/access.log.13.gz
/var/log/app/error.log.9.gz

df -hTの「Use%」列が90%を超えている行が、逼迫しているパーティションです。du -shの結果を容量の大きい順（sort -rh）に並べることで、原因になっているディレクトリの見当がつきます。今回の例では/var/log/appが最も大きく、findで30日以上前の圧縮ログが複数見つかったことから、古いログの蓄積が使用率上昇の主因と推測できます。あくまで一覧表示までの調査であり、この時点ではファイルは1つも削除していません。

安全メモ：ログの削除や圧縮は、対象ファイルを依頼者と一緒に再確認し、必要であれば別のディスクへコピー（バックアップ）を取ってから、承認を得た範囲でのみ実施します。

使用する主なコマンド：dpkg または rpm、nginx -v

【Ubuntu系の場合】
$ dpkg -l | grep nginx
ii  nginx  1.18.0-6ubuntu14.4  amd64  small, powerful, scalable web/proxy server

$ apt list --installed 2>/dev/null | grep nginx
nginx/jammy-updates,now 1.18.0-6ubuntu14.4 amd64 [installed]

$ nginx -v
nginx version: nginx/1.18.0

【RHEL系の場合】
$ dnf list installed nginx
Installed Packages
nginx.x86_64    1:1.20.1-14.el9    @appstream

$ rpm -q nginx
nginx-1.20.1-14.el9.x86_64

$ nginx -v
nginx version: nginx/1.20.1

Ubuntu系ではdpkg -lやapt list --installedの出力の2列目・3列目あたりにバージョン番号が表示されます。RHEL系ではdnf list installedやrpm -qの出力にパッケージ名とバージョンがまとめて表示されます。nginx -vはOSの種類によらず共通で使え、実際に動いているnginx本体のバージョンを直接確認できるため、パッケージ管理側の情報と突き合わせる際の確認用として役立ちます。

使用する主なコマンド：crontab、systemctl、journalctl

$ crontab -l
no crontab for appuser

$ systemctl list-timers --all
NEXT                        LEFT     LAST                         PASSED  UNIT                 ACTIVATES
Sun 2026-08-30 03:00:00 UTC 6h left  Sat 2026-08-29 03:00:01 UTC  17h ago daily-backup.timer   daily-backup.service

$ systemctl status daily-backup.timer
● daily-backup.timer - Run daily-backup.service daily
     Loaded: loaded (/etc/systemd/system/daily-backup.timer; enabled)
     Active: active (waiting) since Mon 2026-08-24 09:00:00 UTC
    Trigger: Sun 2026-08-30 03:00:00 UTC; 6h left

$ journalctl -u daily-backup.service -n 20
Aug 29 03:00:01 web01 systemd[1]: Started daily-backup.service.
Aug 29 03:00:45 web01 backup.sh[2201]: backup completed: /backup/2026-08-29.tar.gz
Aug 29 03:00:45 web01 systemd[1]: daily-backup.service: Deactivated successfully.

今回の例ではcrontab -lには該当ユーザーの設定がなく、代わりにsystemctl list-timers --allでdaily-backup.timerが見つかりました。「LAST」列が直近の実行時刻、「NEXT」列が次回実行予定時刻を示しており、想定どおり深夜3時台に動いていることが読み取れます。さらにjournalctl -u daily-backup.service -n 20で「backup completed」というログが確認できたため、バックアップ自体も正常に完了していると判断できます。もしcronとtimerのどちらにも設定が見つからない場合は、バックアップの仕組み自体を依頼者に確認し直す必要があります。

安全メモ：確認作業では設定ファイルの内容を書き換えず、状態確認のコマンドのみを使用します。もし設定に問題が見つかった場合の修正は、変更内容を依頼者・上長と共有し、承認を得てから実施します。

使用する主なコマンド：hostname、whoami、systeminfo、Get-Process、Get-Service

PS> hostname
AP01
PS> whoami
CORP\y.tanaka
PS> systeminfo

Host Name:                  AP01
OS Name:                     Microsoft Windows Server 2019 Standard
System Boot Time:            2026/08/25, 6:02:15
Total Physical Memory:       16,384 MB
Available Physical Memory:   1,120 MB

PS> Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  ProcessName
-------  ------    -----      -----     ------     --  -----------
    842      45   210344     215600   1523.45    4032  w3wp
    312      22    45210      52800    312.11    1244  sqlservr
    198      15    18320      21400     98.02     880  MsMpEng

PS> Get-Service | Where-Object Status -eq "Running"

Status   Name               DisplayName
------   ----               -----------
Running  W3SVC              World Wide Web Publishing Service
Running  MSSQLSERVER        SQL Server (MSSQLSERVER)
Running  WinRM              Windows Remote Management

systeminfoの起動時刻から長期間再起動されていないこと、空きメモリが少なめであることがわかります。Get-Processの結果では、w3wpのCPU使用時間が突出しています。w3wpは、IIS（Windowsに標準で付いているWebサーバー機能）がWebアプリを動かすためのプロセス（アプリケーションプール）です。ここから、Webアプリケーション側の処理に時間がかかっている可能性が読み取れます。Get-Serviceで想定されるサービスがすべてRunningであれば、少なくともサービス停止による障害ではないと判断できます。これらはあくまで一次切り分けの材料であり、断定するにはアプリケーションログなど追加の確認が必要です。

使用する主なコマンド：Resolve-DnsName、Get-NetIPConfiguration、Test-NetConnection

PS> Resolve-DnsName server01

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
server01                                       A      3600  Answer     10.0.20.15

PS> Get-NetIPConfiguration

InterfaceAlias        : イーサネット
IPv4Address           : 10.0.20.101
IPv4DefaultGateway    : 10.0.20.1
DNSServer             : 10.0.20.5

PS> Test-NetConnection server01 -Port 443

ComputerName     : server01
RemoteAddress    : 10.0.20.15
RemotePort       : 443
TcpTestSucceeded : True

Resolve-DnsNameで名前解決ができ、Get-NetIPConfigurationから確認端末が社内ネットワーク（10.0.20.0/24相当）に属し、DNSサーバーも社内のものが設定されていることがわかります。Test-NetConnectionの結果でTcpTestSucceededがTrueであれば、TCP（通信の土台になる決まりごと）のレベルでは疎通（通信が相手まで届くこと）に成功しています。ただしHTTPSの応答内容（証明書やアプリケーションの動作）まではこの確認だけでは判断できないため、実際のWeb画面表示は別途確認が必要です。

使用する主なコマンド：uptime、free、systemctl、journalctl、ss、curl

$ uptime
 09:14:32 up 12 days,  3:41,  1 user,  load average: 0.42, 0.38, 0.35

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.1Gi       1.9Gi        45Mi       800Mi       2.5Gi
Swap:          2.0Gi          0B       2.0Gi

$ systemctl --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service   loaded failed failed A high performance web server

1 loaded units listed.

$ sudo journalctl -p err --since "2 hours ago"
Aug 30 08:03:11 web01 systemd[1]: nginx.service: Main process exited, code=killed, status=9/KILL
Aug 30 08:03:11 web01 systemd[1]: nginx.service: Failed with result 'signal'.

$ sudo ss -tulnp
Netid State  Local Address:Port Peer Address:Port Process
tcp   LISTEN 0.0.0.0:22        0.0.0.0:*        users:(("sshd",pid=812,fd=3))

uptimeとfree -hから、負荷やメモリ不足が原因ではなさそうだと分かります。systemctl --failedでnginxがfailed状態であること、journalctl -p err --since "2 hours ago"（-p errは重要度がerr以上のログだけに絞り込み、--sinceは確認する開始時刻を指定するオプションです）の「Main process exited, code=killed, status=9/KILL」という行が見つかります。この行から、プロセスが外部要因で強制終了させられた可能性が読み取れます。ss -tulnpの一覧に80番ポートが出てこないことから、Webサーバーが応答できない状態にあると外形的にも裏付けが取れます。ここまでの確認はすべて参照のみで、まだ何も変更していません。オプションの詳しい意味はLinuxコマンド集のサービスとログも参照してください。

$ sudo systemctl restart nginx

$ systemctl status nginx
● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2026-08-30 09:16:02 JST; 5s ago
 Main PID: 15234 (nginx)

$ curl -I --max-time 5 http://localhost
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Sun, 30 Aug 2026 00:16:07 GMT
Content-Type: text/html

再起動後はsystemctl statusの表示がactive (running)になっていること、curl -IでHTTP/1.1 200 OKが返ってくることの2点がそろって初めて、サービスが外部から見ても応答できる状態に戻ったと判断できます。片方だけでは復旧したと言い切らないよう注意します。

報告例（事実・推測・未確認を分ける）：「事実：09:14時点でnginxがfailed状態、80番ポート未待受を確認。09:16に再起動し、active (running)とHTTP 200応答を確認しました。推測：signal 9による強制終了のため、OOM Killerや監視ツールによる停止の可能性があります。未確認：強制終了の直接原因はログの深堀りが必要で、まだ特定できていません。」

signal 9は「プロセスを問答無用で終了させる合図」です。OOM Killerは、メモリが足りなくなったときにLinuxが自動で重いプロセスを強制終了する仕組みを指します。

安全メモ：対象がweb01で間違いないかホスト名を再確認し、再起動前に上長へ一言承認を取ってから実行します。再起動でも復旧しない場合に備え、設定ファイルのバックアップの有無と切り戻し方法を事前に確認し、無関係なサービスやサーバーには一切手を触れません。