---
title: 【LPICの講師応援公開】LPIC-1 _ 101-500原理原則と図解（未経験・文系出身の新人エンジニアのための 7 日間集中研修）コマンド暗記ではなく、なぜそう動くのかを図で理解する編
tags: 
author: [Yukiko](https://docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PJXQX4M17X.jpg?width=480
description: 【LPICの講師応援公開】LPIC-1 _ 101-500原理原則と図解（未経験・文系出身の新人エンジニアのための 7 日間集中研修）コマンド暗記ではなく、なぜそう動くのかを図で理解する編 by Yukiko
published: April 23, 26
canonical: https://docswell.com/s/yukiko_it/ZN7LNL-2026-04-23-072821
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/PJXQX4M17X.jpg)

LPIC-1 / 101-500
原理原則と図解
Principles &amp; Diagrams
未経験・文系出身の新人エンジニアのための 7 日間集中研修
コマンド暗記ではなく、なぜそう動くのかを図で理解する
IT Instructor: Yukiko


# Page. 2

![Page Image](https://bcdn.docswell.com/page/3JK9WZGMJD.jpg)

7 日間の旅
ブートから
パッケージまで
各 Day は「原理 → 図解」の 1 単位で構成
1
システム起動とブートローダー
2
ファイルシステム階層とマウント
3
ファイル・権限・iノード
4
シェルと標準入出力
5
プロセス管理とシグナル
6
カーネルとデバイス
7
パッケージとファイルシステム管理
BIOS / UEFI / GRUB / init が動くまで
FHS, /proc, mount --bind, systemd
rwx, umask, ハード/シンボリックリンク
リダイレクト・パイプ・クォート
PID, nice, nohup, SIGINT, SIGTERM…
モジュール, dmesg, /proc/interrupts
dpkg / rpm, mkfs, tune2fs, 共有ライブラリ


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE3W1DN2E5.jpg)

面白きこともなき世を面白く
Yukiko
DAY 1 / 7
システム起動とブートローダー
BIOS と UEFI — 起動の二つの世界
原理
図解
電源投入直後、
最初に動くのはハードウェア上の ファーム
ウェア。
BIOS / MBR
UEFI / GPT
古くからの BIOS は MBR の先頭 512B を読む
だけ。
ファームウェア起動
ファームウェア起動
UEFI はファイルシステム（FAT32）を理解し
、
MBR 先頭 512B 読込
ESP (FAT32) を直接認識
ブートローダー起動
GPT を読みブート選択
カーネルへ渡す
カーネルへ渡す
GPT パーティションを直接解釈できる。
→ ブートローダーの置き場所と読み方がま
ったく違う。
Day 1 — Boot Process


# Page. 4

![Page Image](https://bcdn.docswell.com/page/8EDKXPW67G.jpg)

面白きこともなき世を面白く
Yukiko
DAY 1 / 7
システム起動とブートローダー
GRUB 2 — 2 段構えで カーネルを呼び出す
原理
図解
ブートローダーの役目は、
「カーネルをメモリに載せ、制御を渡す」こ
と。
GRUB 2 は極小コード (core.img) がまず起動し
、
MBR /
ESP
core.img
(小さな本体)
grub.cfg
(設定を読む)
vmlinuz
(カーネル)
/boot/grub/grub.cfg を読んでメニューを表示
、
選ばれたカーネルとパラメータを渡して終了
する。
※ 旧 GRUB Legacy の stage1/stage2 とは構造
が違う。
設定ファイル: /boot/grub/grub.cfg
モジュール群: /boot/grub/i386-pc/*.mod
MBR への書き込み: grub-install /dev/sdX
Day 1 — Boot Process


# Page. 5

![Page Image](https://bcdn.docswell.com/page/V7PKPNXZJ8.jpg)

面白きこともなき世を面白く
Yukiko
DAY 1 / 7
システム起動とブートローダー
/proc/cmdline — ブートローダーからの「置き手紙」
原理
図解
GRUB が vmlinuz を呼ぶとき、
カーネルに文字列パラメータを渡す。
起動後のシステムからそれを読む窓口が
パラメータを渡す
GRUB 2
Kernel
(vmlinuz)
linux …
ro root=UUID=…
/proc/cmdline。
root= や quiet, splash, init= など、
公開
「今のカーネルはどう起動したか」が一行で
わかる。
/proc/cmdline
BOOT_IMAGE=/vmlinuz-6.x
root=UUID=…
ro
quiet
splash
→ いつでも $ cat /proc/cmdline で確認できる
Day 1 — Boot Process


# Page. 6

![Page Image](https://bcdn.docswell.com/page/2JVV2KLMJQ.jpg)

面白きこともなき世を面白く
Yukiko
DAY 1 / 7
システム起動とブートローダー
init — 最初に生まれる PID 1、すべての祖先
原理
図解
Kernel ───→ /sbin/init を exec()
カーネルは起動の最後に、
ユーザー空間の最初のプロセス /sbin/init を
起動する。
init
PID 1
このプロセスは例外なく PID=1。
以後のすべてのプロセスは init の子孫。
PID 1 が死ぬとカーネルはパニックする。
※ 現代の多くのディストリでは systemd が
init を務める。
getty
sshd
cron
NetworkManager
…さらに多数の子プロセス
Day 1 — Boot Process


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5EGLRQXXJL.jpg)

面白きこともなき世を面白く
Yukiko
DAY 2 / 7
ファイルシステム階層とマウント
FHS — Linux ディレクトリの「住所割り当て」
原理
図解
どのディストリでも、
/
ディレクトリの役割はほぼ共通。
これを決めているのが Filesystem Hierarchy
Standard。
「どこに何を置くか」を知っていれば、
未知のシステムでも迷わず探せる。
例: man ページは /usr/share/man/ — 必ず。
/bin
/sbin
/etc
/home
基本コマンド
管理者コマンド
設定ファイル
ユーザー領域
/usr
/var
/proc
/dev
共有・読み取り専用
可変データ・ログ
カーネルの窓 (仮想)
デバイスファイル
Day 2 — Filesystem &amp; Mount


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JQYVK857P.jpg)

面白きこともなき世を面白く
Yukiko
DAY 2 / 7
ファイルシステム階層とマウント
/proc — カーネル内部を覗く「仮想の窓」
原理
図解
/proc は ディスク上に存在しない。
カーネルのメモリ上の情報を、
ファイルのように見せている仮想ファイルシ
ステム。
Kernel
Memory
• プロセス情報
cat で読むだけで、
• CPU 情報
プロセス・CPU・メモリ・割り込みなどの
• メモリ使用量
「今この瞬間」の状態が取り出せる。
• 割り込み統計
• 起動パラメータ
/proc/cpuinfo
/proc/meminfo
/proc/cmdline
/proc/interrupts
/proc/self/mounts
Day 2 — Filesystem &amp; Mount


# Page. 9

![Page Image](https://bcdn.docswell.com/page/K74WMP2VE1.jpg)

面白きこともなき世を面白く
Yukiko
DAY 2 / 7
ファイルシステム階層とマウント
mount --bind — 同じ中身を別の場所からも見せる
原理
図解
通常のマウントはデバイスをマウントする。
--bind は ディレクトリを別のディレクトリに
投影する。
/data/logs
/srv/www/logs
2 箇所の入り口から、同じ 1 つの中身が見え
る。
コピーではない — 同じ iノードを共有する。
# mount --bind /data/logs /srv/www/logs
chroot 環境の構築や、
特定ディレクトリの再配置に使われる。
同じ実体
(同じ iノード・同じデータ)
Day 2 — Filesystem &amp; Mount


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LJ1Y89M4EG.jpg)

面白きこともなき世を面白く
Yukiko
DAY 2 / 7
ファイルシステム階層とマウント
systemd の自動マウントユニット生成
原理
図解
systemd は /etc/fstab に無い マウントも、
手動で mount された瞬間に検出する。
そして /run/systemd/generator/ に
一時的な .mount ユニットを自動生成して監
視する。
勝手にアンマウントはしない。
手動で
mount 実行
systemd が
検出
/run/systemd/
generator/*.mount
監視開始
(変更はしない)
「状態を把握する」のが目的。
重要 : systemd は勝手にアンマウントしない — 単に認識して監視するだけ
Day 2 — Filesystem &amp; Mount


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJWGZQ3Z72.jpg)

面白きこともなき世を面白く
Yukiko
DAY 3 / 7
ファイル・権限・iノード
iノードとハードリンク — ファイル名は「別名」
原理
図解
Linux では、
ファイルの実体 = iノード + データブロック
。
ファイル名はディレクトリが持つ「iノードへ
の参照」にすぎない。
report.txt
summary.txt
iノード #42
所有者 / 権限 / サイズ
ハードリンクは、同じ iノードに別名をつけ
る操作。
データブロック
所有者・権限・内容はすべて共有される。
元を消しても、残ったリンクでアクセスでき
る。
2 つの名前が同じ iノードを指す = ハードリンク
Day 3 — Files &amp; Permissions


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4EZL1WVL73.jpg)

面白きこともなき世を面白く
Yukiko
DAY 3 / 7
ファイル・権限・iノード
ハードリンクの限界、シンボリックリンクの役割
原理
図解
ハードリンクは iノード番号で指すため、
同じファイルシステム内でしか作れない。
別ディスク・別パーティションにはリンクで
きない。
シンボリックリンクは「パス文字列」を指す
。
ファイルシステムを越えて使える / ディレク
トリもリンク可。
その代わり、リンク先が消えれば壊れる。
Filesystem A
(/dev/sda1)
Filesystem B
(/dev/sdb1)
✗ hard link 不可
別の iノード空間
file.txt (iノード #42)
シンボリックリンクなら OK
ln -s /mnt/B/target.txt
/home/user/link
→ パス文字列で指すので、ファイルシステムを跨いでも動く
Day 3 — Files &amp; Permissions


# Page. 13

![Page Image](https://bcdn.docswell.com/page/Y76WLG5M7V.jpg)

面白きこともなき世を面白く
Yukiko
DAY 3 / 7
ファイル・権限・iノード
rwx — 3 × 3 の権限マトリクス
原理
図解
Linux のパーミッションは、
「誰が × 何をできるか」の 3 × 3 で決まる。
r (4)
w (2)
x (1)
Owner
r
w
x
Group
r
-
x
Other
-
-
-
誰が: 所有者 / グループ / その他
何を: 読み (r) / 書き (w) / 実行 (x)
数値モードは r=4, w=2, x=1 の合計。
例: rwxr-x--- → 750
例: rwxr-x---
=
7 5 0
(4+2+1)(4+0+1)(0+0+0)
Day 3 — Files &amp; Permissions


# Page. 14

![Page Image](https://bcdn.docswell.com/page/G75M1VYQ74.jpg)

面白きこともなき世を面白く
Yukiko
DAY 3 / 7
ファイル・権限・iノード
umask — 「引き算」で決まるデフォルト権限
原理
図解
新しく作るファイル / ディレクトリの
デフォルト権限は umask が決める。
仕組みは単純な引き算:
ディレクトリ: 777 − umask
ファイル:
666 − umask
例: umask 027 → ディレクトリは 750、ファイ
ルは 640
777
最大権限
−
027
umask
=
750
実際の権限
所有者: rwx (7) / グループ: r-x (5) / その他: --- (0)
「マスク」= 隠す、なので権限を削る数値
Day 3 — Files &amp; Permissions


# Page. 15

![Page Image](https://bcdn.docswell.com/page/9J2913GWER.jpg)

面白きこともなき世を面白く
Yukiko
DAY 3 / 7
ファイル・権限・iノード
SetGID ディレクトリ — グループの自動継承
原理
図解
複数ユーザーで共同作業するディレクトリで
、
新規ファイルのグループが作成者のプライマ
リでは困る。
drwxrws--- sales/home/shared
s
SetGID ビット (chmod g+s) を立てると、
そのディレクトリの下に作られるファイルは
自動で、
親ディレクトリのグループを継承する。
(drwxrws--- sales)
alice
(primary: alice)
bob
(primary: bob)
A.txt → group: sales
B.txt → group: sales
数値では 2xxx（例: 2775）で指定できる。
Day 3 — Files &amp; Permissions


# Page. 16

![Page Image](https://bcdn.docswell.com/page/DEY4Z1V9JM.jpg)

面白きこともなき世を面白く
Yukiko
DAY 4 / 7
シェルと標準入出力
3 つのストリーム — プロセスの口・耳・悲鳴
原理
図解
すべての UNIX プロセスは、
起動時に 3 つのファイルディスクリプタを持
つ。
stdout (fd 1)
fd 0 標準入力 (stdin) — 読み込み
fd 1 標準出力 (stdout) — 通常の出力
fd 2 標準エラー (stderr) — エラーのみ
出力とエラーを分けるのが UNIX 流。
stdin
(fd 0)
process
stderr (fd 2)
→ stdout と stderr を別に扱えるから、ログと結果を分離できる
Day 4 — Shell &amp; I/O


# Page. 17

![Page Image](https://bcdn.docswell.com/page/VJNY32MD78.jpg)

面白きこともなき世を面白く
Yukiko
DAY 4 / 7
シェルと標準入出力
リダイレクトとパイプ — 流れを付け替える
原理
図解
シェルはプロセスの起動前に、
ファイルディスクリプタの接続先を差し替え
られる。
&gt; stdout をファイルへ（上書き）
cmd &gt; out.txt
結果をファイルへ
cmd &gt;&gt; out.txt
追記モード
cmd &lt; input.txt
ファイルを入力に
cmd 2&gt; err.log
エラーだけ別ファイル
cmd &gt; out.txt 2&gt;&amp;1
出力もエラーも同じ所へ
cmd1 | cmd2
パイプで次へ流す
&gt;&gt; stdout をファイルへ（追記）
&lt; stdin をファイルから
2&gt;&amp;1 stderr を stdout と同じ先へ
| stdout を次コマンドの stdin へ
Day 4 — Shell &amp; I/O


# Page. 18

![Page Image](https://bcdn.docswell.com/page/YE9P91N8J3.jpg)

面白きこともなき世を面白く
Yukiko
DAY 4 / 7
シェルと標準入出力
クォーティング — 何が展開され、何が守られるか
原理
図解
シェルは空白・変数・特殊文字を解釈する。
クォートはその解釈を制御する鍵。
&#039; ... &#039; （シングル） すべて文字通り
&quot; ... &quot; （ダブル） 変数は展開する
\ （バックスラッシュ） 次の 1 文字だけ守
る
「$ を見せたいか、値に置き換えたいか」で
選ぶ。
シングル &#039;...&#039; — そのまま
echo &#039;$USER&#039;
→
$USER
→
fred
変数は展開されず、文字 $USER がそのまま出る
ダブル &quot;...&quot; — 展開される
echo &quot;$USER&quot;
$USER はユーザー名に置き換わる
Day 4 — Shell &amp; I/O


# Page. 19

![Page Image](https://bcdn.docswell.com/page/GE8D94KZED.jpg)

面白きこともなき世を面白く
Yukiko
DAY 4 / 7
シェルと標準入出力
source と 実行 — 同じシェルか、子シェルか
原理
図解
スクリプトを普通に実行すると、
新しい子シェル（サブシェル）が起動して実
行される。
./script.sh
source script.sh
/
. script.sh
子の中で変えた環境変数は、親に戻らない。
source (または . ) は、
Parent Shell
現在のシェルの中でスクリプトを実行する。
環境変数や関数を読み込みたいときに使う。
Subshell
(スクリプト実行)
変更は消える
Current Shell
(この中で直接実行)
変更はここに残る
Day 4 — Shell &amp; I/O


# Page. 20

![Page Image](https://bcdn.docswell.com/page/LELMW6Z17R.jpg)

面白きこともなき世を面白く
Yukiko
DAY 4 / 7
シェルと標準入出力
tee — 流れを二手に分ける「T 字継手」
原理
図解
&gt; でリダイレクトするとファイルに入るが、
画面には何も出なくなる。
画面 (stdout)
tee は stdin を両方に流す。
画面（stdout）へそのまま通しつつ、
ファイルにも同時に書き込む。
名前の由来は水道管の T 字継手。
cmd
|
tee
ファイル
例: cmd | tee log.txt — 画面で結果を見つつ、 log.txt にも残す
Day 4 — Shell &amp; I/O


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4JMY95V5JW.jpg)

面白きこともなき世を面白く
Yukiko
DAY 5 / 7
プロセス管理とシグナル
プロセスは家系図 — 親子と PID
原理
図解
Linux のプロセスは必ず親を持つ。
fork() で親のコピーが生まれ、exec() で中身
が入れ替わる。
init PID 1
PID = プロセス固有番号、PPID = 親の PID。
PID 1 (init/systemd) を頂点とする一本の家系
図。
親が先に死んだ子は「孤児」になり、
sshd
PID 840
bash
PID 1205
cron
PID 640
init が里親として引き取る。
vim
PID 1310
ps -ef
python
PID 1402
/
pstree
で観察できる
Day 5 — Processes &amp; Signals


# Page. 22

![Page Image](https://bcdn.docswell.com/page/PJR9G32Z79.jpg)

面白きこともなき世を面白く
Yukiko
DAY 5 / 7
プロセス管理とシグナル
nice 値 — CPU の譲り合い度合い
原理
図解
nice 値はプロセスの「CPU 譲り合い度」。
範囲は −20 〜 +19。
低いほど優先度が高く (急ぐ)、
最高優先度
最低優先度
高いほど優先度が低い (譲る)。
一般ユーザーは 0 〜 19 しか設定できない。
−20
0
+19
マイナス値は root 権限が必要。
デフォルト
一般ユーザーが設定可能: 0 〜 +19
例: nice -n 10 ./heavy.sh
renice 5 -p 1234
Day 5 — Processes &amp; Signals


# Page. 23

![Page Image](https://bcdn.docswell.com/page/PEXQX4D1JX.jpg)

面白きこともなき世を面白く
Yukiko
DAY 5 / 7
プロセス管理とシグナル
シグナル — プロセスに送る非同期の合図
原理
図解
シグナルは短い通知メッセージ。
カーネルやユーザーからプロセスに送られる
。
名称
番号
典型トリガ
意味
種類によって意味が決まっており、
SIGINT
2
Ctrl + C
中断要求
プロセスは捕まえて処理するか、既定動作に
従う。
SIGTERM
15
kill 既定
穏やかに終了
KILL と STOP だけは捕まえられない。
SIGKILL
9
kill -9
強制終了 (無視不可)
SIGSTOP
19
—
一時停止 (無視不可)
SIGTSTP
20
Ctrl + Z
一時停止要求
SIGCONT
18
fg / bg
停止から再開
kill コマンドは「殺す」ではなく「送る」。
Day 5 — Processes &amp; Signals


# Page. 24

![Page Image](https://bcdn.docswell.com/page/3EK9WZXMED.jpg)

面白きこともなき世を面白く
Yukiko
DAY 5 / 7
プロセス管理とシグナル
nohup と &amp; — ログアウトを生き延びる
原理
図解
ターミナルを閉じると、
シェルは子プロセスに SIGHUP を送って終わ
る。
普通の &amp;
cmd &amp;
&amp; はバックグラウンドに回すだけで、SIGHUP
は届く。
nohup は HUP を無視させ、出力を nohup.out
へ退避する。
合わせて nohup cmd &amp; とすれば、
実行中
SIGHUP
終了 ✗
SIGHUP 無視
継続 ✓
nohup cmd &amp;
nohup cmd &amp;
実行中
ログアウト後もコマンドは生き続ける。
ログアウト直後
現代的な選択肢: screen / tmux / systemd-run
Day 5 — Processes &amp; Signals


# Page. 25

![Page Image](https://bcdn.docswell.com/page/L73W1D5275.jpg)

面白きこともなき世を面白く
Yukiko
DAY 6 / 7
カーネルとデバイス
カーネルモジュール — 着脱できるドライバ
原理
図解
Linux カーネルはモノリシックだが、
必要に応じて機能を動的に追加できる。
これが カーネルモジュール (.ko)。
e1000e
(NIC)
usbhid
(USB HID)
lsmod 読み込み済み一覧
modprobe 依存解決しつつロード
Kernel Core
(常駐部分)
modprobe -r アンロード (一時的)
情報は /proc/modules と modinfo で確認。
btrfs
(FS)
nvidia
(GPU)
bluetooth
cifs
Day 6 — Kernel &amp; Devices


# Page. 26

![Page Image](https://bcdn.docswell.com/page/87DKXPD6JG.jpg)

面白きこともなき世を面白く
Yukiko
DAY 6 / 7
カーネルとデバイス
blacklist — 起動時に特定モジュールを除外
原理
図解
modprobe -r は一時的なアンロード。
再起動すれば、また自動でロードされてしま
う。
/etc/modprobe.d/blacklist-nouveau.conf
永続的に読ませないには、
blacklist nouveau
blacklist lbm-nouveau
/etc/modprobe.d/*.conf に blacklist 行を書く
。
このディレクトリの .conf を modprobe が読み
、
起動時に読み込まれる
起動時の自動ロード対象から除外される。
e1000e
usbhid
nouveau
btrfs
✗ ブロック
Day 6 — Kernel &amp; Devices


# Page. 27

![Page Image](https://bcdn.docswell.com/page/VJPKPN6ZE8.jpg)

面白きこともなき世を面白く
Yukiko
DAY 6 / 7
カーネルとデバイス
カーネルリングバッファ — 上書きされる循環ログ
原理
図解
カーネルが出すメッセージは、
固定サイズの円環バッファに書き込まれる。
古いものは新しいものに押し出され、
サイズを超えると消える。
dmesg で内容を表示、dmesg --clear で消去。
再起動でも消える。起動直後の問題調査に有
用。
カーネル
メッセージ
Ring
Buffer
dmesg
が読む
古いメッセージは自動的に押し出される
Day 6 — Kernel &amp; Devices


# Page. 28

![Page Image](https://bcdn.docswell.com/page/2EVV2K3MEQ.jpg)

面白きこともなき世を面白く
Yukiko
DAY 6 / 7
カーネルとデバイス
/proc/interrupts — 割り込みの家計簿
原理
図解
ハードウェアは処理を求めるときカーネルに
割り込み (IRQ) を送る。
/proc/interrupts は、
「どの IRQ が、どの CPU で、何回起きたか
」を記録する。
デバイスの異常や CPU 偏りの調査に使う。
関連: /proc/ioports (I/O ポート割当)
IRQ
CPU0
CPU1
CPU2
CPU3
Type
Device
0
1234
0
0
0
IO-APIC
timer
1
8
12
4
0
IO-APIC
i8042
9
0
0
0
0
IO-APIC
acpi
16
5120
3021
982
77
IO-APIC
ehci_hcd
19
1042
2081
4920
3201
IO-APIC
eth0
23
5
2
1
0
IO-APIC
snd_hda
$ cat /proc/interrupts
Day 6 — Kernel &amp; Devices


# Page. 29

![Page Image](https://bcdn.docswell.com/page/57GLRQ3XEL.jpg)

面白きこともなき世を面白く
Yukiko
DAY 7 / 7
パッケージ管理とファイルシステム管理
パッケージ管理 — Debian 系と Red Hat 系
原理
図解
Linux のパッケージ管理には二大系統がある
。
Debian 系
Red Hat 系
Debian / Ubuntu / Mint
RHEL / CentOS / Fedora / openSUSE
Debian 系: .deb / dpkg (低) / apt (高)
Red Hat 系: .rpm / rpm (低) / dnf・yum・
zypper (高)
低レベル
dpkg
低レベル
rpm
低レベルは「1 個のパッケージ」を扱い、
高レベル
apt / apt-get
高レベル
dnf / yum / zypper
形式
.deb
形式
.rpm
検索
apt search / dpkg -l
情報表示
rpm -qi
設定保持削除
dpkg -r
依存関係表示
rpm -qpR
完全削除
dpkg -P
インストール
dnf install
高レベルは 依存解決と リポジトリを扱う。
違う系統のパッケージ形式は互換性なし。
Day 7 — Packages &amp; FS Admin


# Page. 30

![Page Image](https://bcdn.docswell.com/page/4EQYVK55JP.jpg)

面白きこともなき世を面白く
Yukiko
DAY 7 / 7
パッケージ管理とファイルシステム管理
削除の二段階 — 設定を残すか、消し去るか
原理
図解
パッケージは、バイナリと 設定ファイルに分
かれている。
nginx (インストール済み)
削除には二つの深さがある。
/usr/sbin/nginx
+
/etc/nginx/*
remove (-r): バイナリだけ消す。設定は残す
。
purge (-P): 設定も含めて完全消去。
再インストール時に以前の設定を引き継ぎた
いなら -r。
dpkg -r nginx
dpkg -P nginx
バイナリ ×
/etc/nginx/* ○ 残る
バイナリ ×
/etc/nginx/* × 完全消去
まっさらにやり直したいなら -P。
Day 7 — Packages &amp; FS Admin


# Page. 31

![Page Image](https://bcdn.docswell.com/page/KJ4WMP9V71.jpg)

面白きこともなき世を面白く
Yukiko
DAY 7 / 7
パッケージ管理とファイルシステム管理
パーティションタイプ — 用途を示す番号札
原理
図解
MBR のパーティションテーブルには、
各パーティションの用途を示す タイプコー
ドがある。
これによりツールが「この領域は何用か」を
判断する。
83 Linux ネイティブ (ext4 など)
82 Linux swap
83
82
8e
fd
Linux
Linux swap
Linux LVM
Linux RAID
ext4, xfs, btrfs など
の通常ファイルシステ
ム
スワップ領域
論理ボリューム
管理の物理ボリューム
ソフトウェア RAID の
構成要素
8e LVM / fd Linux RAID
fdisk /dev/sdX で t コマンドで変更
Day 7 — Packages &amp; FS Admin


# Page. 32

![Page Image](https://bcdn.docswell.com/page/LE1Y89K47G.jpg)

面白きこともなき世を面白く
Yukiko
DAY 7 / 7
パッケージ管理とファイルシステム管理
tune2fs — ext ファイルシステムの「チューニング」
原理
図解
mkfs.ext4 で作った後でも、
ファイルシステムの挙動は後から変更できる
。
その専用ツールが tune2fs。
ext4
Filesystem
-c 何回マウントごとに fsck するか
-i 何日ごとに fsck するか (0=無効)
5% root 予約
-m root 予約領域の % (既定 5%)
mkfs.ext4 の既定は 5% が root 用に予約される
。
95% 通常利用
tune2fs オプション
-c 30
30 回マウントごとに fsck
-i 200
200 日ごとに fsck
-m 1
root 予約を 1% に変更
-L data
ラベルを data に設定
-j
ext2 → ext3 化（ジャーナル追加
）
Day 7 — Packages &amp; FS Admin


# Page. 33

![Page Image](https://bcdn.docswell.com/page/GEWGZQDZJ2.jpg)

面白きこともなき世を面白く
Yukiko
DAY 7 / 7
パッケージ管理とファイルシステム管理
共有ライブラリ — 複数の実行ファイルで一つを共有
原理
図解
多くのプログラムは共通のコード (libc など)
を使う。
各プログラムに同じコードを埋め込むのは無
駄。
bash
ssh
ls
python
→ 実行時に動的に読み込む共有ライブラリ
(.so) を使う。
64-bit 版の標準的な置き場は /lib64, /usr/lib64
。
依存調査: ldd /path/to/binary
検索パス設定: /etc/ld.so.conf + ldconfig
/lib64/libc.so.6
共有ライブラリ (glibc)
メモリ上に 1 つ、みんなで使う
Day 7 — Packages &amp; FS Admin


# Page. 34

![Page Image](https://bcdn.docswell.com/page/47ZL1WGLJ3.jpg)

CLOSING
コマンドではなく、原理で理解する
Understand by principle, not by command.
同じ図を 3 つの角度で説明できたら、あなたは理解している。
未知のコマンドに出会っても、原理があれば読み解ける。
本試験 (101-500) に向けて、明日からは実機演習で定着させよう。
Yukiko ｜ 面白きこともなき世を面白く


