【LPICの講師応援公開】LPIC-1 _ 101-500原理原則と図解（未経験・文系出身の新人エンジニアのための 7 日間集中研修）コマンド暗記ではなく、なぜそう動くのかを図で理解する編

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

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, 共有ライブラリ

面白きこともなき世を面白く 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

面白きこともなき世を面白く 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

面白きこともなき世を面白く 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

面白きこともなき世を面白く 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

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

面白きこともなき世を面白く 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 & Mount

面白きこともなき世を面白く 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 & Mount

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

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

面白きこともなき世を面白く 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 & Permissions

面白きこともなき世を面白く 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 & Permissions

面白きこともなき世を面白く 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 & Permissions

面白きこともなき世を面白く 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 & Permissions

面白きこともなき世を面白く 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 & I/O

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

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

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

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

面白きこともなき世を面白く 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 & Signals

面白きこともなき世を面白く 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 & Signals

面白きこともなき世を面白く 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 & Signals

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

面白きこともなき世を面白く 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 & Devices

面白きこともなき世を面白く 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 & Devices

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

面白きこともなき世を面白く 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 & Devices

面白きこともなき世を面白く 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 & FS Admin

面白きこともなき世を面白く 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 & FS Admin

面白きこともなき世を面白く 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 & FS Admin

面白きこともなき世を面白く 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 & FS Admin

面白きこともなき世を面白く 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 & FS Admin

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