Linuxエンジニア養成講座 第30回|全36回・フェーズ4「サーバー構築と運用」の第3回目(3/9回目)です。
前回: 第29回で Apache をインストールし、firewalld のポート許可と自己署名証明書による HTTPS 体験を行いました。
今回学ぶこと: MariaDB をインストールし、初期セキュリティ設定からデータベース・ユーザー作成、CRUD 操作、mysqldump によるバックアップまでを実践します。
前回の予告で「MariaDB のインストールから初期設定、ユーザー作成、データベース作成、基本的な CRUD 操作、mysqldump によるバックアップまでを実践します。Web サーバーとデータベースを組み合わせると、いわゆる LAMP スタック(Linux + Apache + MariaDB + PHP)の基盤が整います」とお伝えしました。今回はその LAMP スタックの DB 層にあたる MariaDB を扱います。
この記事を読み終えると、以下のことができるようになります。
- データベースがなぜ必要かを、テキストファイル管理との比較で説明できる
- MariaDB をインストールし、systemctl で起動・自動起動設定ができる
- 初期セキュリティ設定(root パスワード設定・匿名ユーザー削除・test DB 削除)を実施できる
- データベースとアプリ用ユーザーを作成し、CRUD(INSERT / SELECT / UPDATE / DELETE)を実行できる
- mysqldump でデータベースのバックアップを取得できる
なぜデータベースが必要か
ここで1つ考えてみてください。もしアプリケーションのデータをすべてテキストファイルで管理したら、どんな問題が起きるでしょうか。
たとえば、社員名簿を CSV ファイルで管理するとします。最初のうちは問題ないかもしれません。しかし、次のような状況を想像してみてください。
- 同時アクセス: 2人の管理者が同時にファイルを開いて別々の行を編集した。保存したら片方の変更が消えた
- 検索効率: 社員が1万人になった。「開発部の社員だけ抽出したい」とき、毎回ファイル全体を読み込んで grep する必要がある
- データ整合性: 部署名を「開発部」から「開発1部」に変更したいが、1万行のうちどの行が該当するか手作業で探す必要がある。1行でも漏れがあればデータが矛盾する
データベース(DB)は、これらの問題を解決するために設計された専用ソフトウェアです。データの安全な保管と効率的な検索を、ファイル操作ではなく DB に任せるという設計思想です。具体的には、同時アクセスの排他制御、インデックスによる高速検索、トランザクションによるデータ整合性の保証といった機能を提供します。
今回使う MariaDB は、MySQL から派生したオープンソースのリレーショナルデータベース管理システム(RDBMS)です。AlmaLinux 9 の AppStream リポジトリに含まれており、dnf で導入できます。MySQL とコマンド体系がほぼ同じなので、MySQL の経験がそのまま活かせます。
MariaDB をインストールする
alma-main にログインして作業します。
alma-main で実行:
実行コマンド:
$ sudo dnf install -y mariadb-server
インストールが完了したら、バージョンを確認します。
実行コマンド:
$ mariadb --version
実行結果:
mariadb Ver 15.1 Distrib 10.5.29-MariaDB, for Linux (x86_64) using EditLine wrapper
MariaDB 10.5.29 がインストールされました。次に、第13回で学んだ systemctl を使って起動と自動起動を設定します。
実行コマンド:
$ sudo systemctl start mariadb
実行コマンド:
$ sudo systemctl enable mariadb
実行結果:
Created symlink /etc/systemd/system/mysql.service → /usr/lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/mysqld.service → /usr/lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /usr/lib/systemd/system/mariadb.service.
mysql.service と mysqld.service のシンボリックリンクが作られています。これは MariaDB が MySQL と互換性を保つために用意している仕組みです。systemctl start mysql でも systemctl start mariadb でも同じサービスが起動します。
実行コマンド:
$ systemctl status mariadb --no-pager -l
実行結果:
● mariadb.service - MariaDB 10.5 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
Active: active (running) since Sat 2026-04-04 13:22:44 JST; ...
Docs: man:mariadbd(8)
Main PID: 24566 (mariadbd)
Status: "Taking your SQL requests now..."
Active: active (running) と表示されていれば正常に起動しています。Docs: の行に man:mariadbd(8) とあります。man mariadbd で MariaDB デーモンのマニュアルを参照できるので、設定オプションを調べたいときに活用してください。
初期セキュリティ設定
MariaDB をインストールした直後の状態は、セキュリティ上の問題を複数抱えています。まず、現在の状態を確認します。
MariaDB にログインするには mariadb コマンド(または互換の mysql コマンド)を使います。インストール直後は root パスワードが設定されていないため、以下のコマンドでログインできます。
alma-main で実行:
実行コマンド:
$ sudo mariadb -u root -e "SELECT VERSION();"
実行結果:
VERSION()
10.5.29-MariaDB
-u root は MariaDB の root ユーザーでログインする指定、-e は SQL 文を直接渡して実行するオプションです。パスワードなしでログインできてしまいました。
ここで考えてみてください。もしこのサーバーに他のユーザーがログインできる状態だったら、誰でも MariaDB の root 権限でデータベースを操作できてしまいます。全テーブルの削除も、全ユーザーの削除も、何でもできる状態です。
インストール直後には、以下の4つの問題があります。
- root パスワードが設定されていない
- 匿名ユーザー(ユーザー名が空のアカウント)が存在し、誰でもログインできる
- test データベースが存在し、誰でもアクセスできる
- root がリモートからログインできる可能性がある
MariaDB には mysql_secure_installation という対話形式の初期設定スクリプトが用意されていますが、今回は各操作の意味を理解するために、SQL 文を1つずつ実行します。
root パスワードを設定する
alma-main で実行:
実行コマンド:
$ sudo mariadb -u root -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'TrainingPass123';"
出力がなければ成功です。以降、root でログインするときは -p オプションの直後にパスワードを付けて -pTrainingPass123 と指定します(-p とパスワードの間にスペースを入れないのが MariaDB/MySQL の仕様です)。
匿名ユーザーを削除する
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123 -e "DELETE FROM mysql.user WHERE User='';"
mysql.user は MariaDB がユーザー情報を格納している内部テーブルです。User=''(ユーザー名が空)のレコードを削除することで、匿名ユーザーを無効にします。
test データベースを削除する
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123 -e "DROP DATABASE IF EXISTS test;"
IF EXISTS を付けているので、test データベースが存在しない場合でもエラーになりません。
権限テーブルを再読み込みする
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123 -e "FLUSH PRIVILEGES;"
FLUSH PRIVILEGES は、mysql.user テーブルへの直接変更をメモリ上の権限情報に反映させるコマンドです。ALTER USER や GRANT で変更した場合は自動で反映されますが、DELETE FROM mysql.user のように直接テーブルを操作した場合は明示的に FLUSH が必要です。
これで初期セキュリティ設定が完了しました。MariaDB のエラーログは以下の場所に出力されます。起動に失敗した場合や動作がおかしい場合は、このログを確認してください。
実行コマンド:
$ sudo ls -la /var/log/mariadb/
実行結果:
合計 8
drwxr-x---. 2 mysql mysql 25 4月 4 13:22 .
drwxr-xr-x. 8 root root 4096 4月 4 13:22 ..
-rw-rw----. 1 mysql mysql 1736 4月 4 13:22 mariadb.log
/var/log/mariadb/mariadb.log がエラーログのファイルです。トラブル時には sudo tail -50 /var/log/mariadb/mariadb.log で直近のログを確認するのが定石です。
現場のヒヤリハット
ヒヤリハット: root パスワード未設定のまま本番運用
ある現場で、検証環境から本番環境にサーバーを移行したとき、MariaDB の初期セキュリティ設定を忘れたまま運用を開始してしまった事例がありました。root パスワードが未設定のため、サーバーにログインできるユーザーなら誰でもデータベースの全権限を持つ状態でした。幸い外部公開前に気づきましたが、もし顧客データが入った状態で発覚していたら、重大なセキュリティインシデントになっていたはずです。
MariaDB をインストールしたら、最初にやることは初期セキュリティ設定です。「あとでやる」は「永遠にやらない」と同じだと思ってください。
文字コードの設定
MariaDB のデフォルト文字コードを確認します。
alma-main で実行:
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123 -e "SHOW VARIABLES LIKE 'character_set%';"
実行結果:
Variable_name Value
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mariadb/charsets/
注目すべきは character_set_database と character_set_server が latin1(西欧向けの文字コード)になっている点です。この状態でデータベースを作成すると、日本語データを INSERT したときにエラーが発生します。
対策として、データベース作成時に CHARACTER SET utf8mb4 を明示的に指定します。utf8mb4 は4バイトの Unicode に対応した文字コードで、日本語はもちろん絵文字も正しく扱える標準的な文字コードです。MariaDB の utf8 は3バイトまでしか対応しておらず、一部の文字(絵文字など)が保存できないため、新しくデータベースを作るときは utf8mb4 を使うのが現在の標準です。
ヒヤリハット: 文字コード未設定で日本語が保存できない
文字コードを指定せずにデータベースを作成し、日本語データを INSERT すると ERROR 1366 (HY000): Incorrect string value というエラーが発生します。開発中に気づけばよいですが、ステージング環境では英語のテストデータしか使わず、本番で初めて日本語データを入れてエラーになるケースがあります。データベース作成時の文字コード指定は忘れずに行ってください。
データベースとユーザーを作成する
ここからは MariaDB にログインして対話形式で SQL 文を実行します。root ユーザーでログインします。
alma-main で実行:
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123
プロンプトが MariaDB [(none)]> に変わります。これは MariaDB の対話モードに入ったことを示しています。(none) は現在どのデータベースも選択していない状態です。
データベースを作成する
実行コマンド:
MariaDB [(none)]> CREATE DATABASE sampledb CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CHARACTER SET utf8mb4 で文字コードを指定し、COLLATE utf8mb4_general_ci で照合順序(文字の比較ルール)を指定しています。ci は Case Insensitive(大文字・小文字を区別しない)の意味です。
アプリ用ユーザーを作成する
ここで考えてみてください。アプリケーションからデータベースに接続するとき、root ユーザーをそのまま使うとどうなるでしょうか。
root ユーザーは全データベースに対して全権限を持っています。もしアプリケーションにセキュリティ脆弱性があり、SQL インジェクション攻撃を受けた場合、攻撃者は全データベースの削除も、ユーザーの作成も、何でもできてしまいます。
これは 第28回の SELinux で学んだ「最小権限の原則」と同じ設計思想です。Linux のユーザー管理(第10回)で「日常作業を root で行わない」と学んだのと同じ理由で、データベースでもアプリケーション専用のユーザーを作り、必要最小限の権限だけを与えます。
実行コマンド:
MariaDB [(none)]> CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'AppPass456';
'appuser'@'localhost' は「localhost からの接続に限って appuser というユーザーを許可する」という意味です。リモートからの接続は許可されません。
実行コマンド:
MariaDB [(none)]> GRANT ALL PRIVILEGES ON sampledb.* TO 'appuser'@'localhost';
sampledb.* は「sampledb データベースの全テーブル」を意味します。appuser に sampledb への全権限を付与しましたが、他のデータベース(mysql や information_schema など)には一切アクセスできません。CREATE USER や GRANT は権限テーブルを自動で反映するため、ここでは FLUSH PRIVILEGES は不要です。
作成結果を確認する
実行コマンド:
MariaDB [(none)]> SHOW DATABASES;
実行結果:
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sampledb |
+--------------------+
sampledb が一覧に表示されています。information_schema、mysql、performance_schema は MariaDB がシステム内部で使用するデータベースです。これらは削除しないでください。
実行コマンド:
MariaDB [(none)]> SELECT User, Host FROM mysql.user;
実行結果:
+-------------+-----------+
| User | Host |
+-------------+-----------+
| appuser | localhost |
| mariadb.sys | localhost |
| mysql | localhost |
| root | localhost |
+-------------+-----------+
appuser が作成されていることを確認できました。先ほど削除した匿名ユーザー(User 列が空のレコード)は表示されていません。
root の対話モードを終了します。
実行コマンド:
MariaDB [(none)]> EXIT;
CRUD 操作
CRUD は Create(作成)、Read(読み取り)、Update(更新)、Delete(削除)の頭文字を取ったもので、データベース操作の基本4パターンです。ここからは先ほど作成した appuser で sampledb に接続して操作します。
alma-main で実行:
実行コマンド:
$ mariadb -u appuser -pAppPass456 sampledb
プロンプトが MariaDB [sampledb]> に変わります。(none) ではなく [sampledb] になっているのは、sampledb データベースを選択した状態でログインしたためです。
Create: テーブルを作成する
まずデータを格納するテーブルを作成します。テーブルはデータベース内の「表」にあたるもので、行(レコード)と列(カラム)でデータを管理します。
実行コマンド:
MariaDB [sampledb]> CREATE TABLE employees (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
department VARCHAR(50)
) CHARACTER SET utf8mb4;
各カラムの意味は次のとおりです。
id INT AUTO_INCREMENT PRIMARY KEY: 整数型の ID。データを追加するたびに自動で1ずつ増える。主キー(行を一意に識別するカラム)として設定name VARCHAR(50): 最大50文字の可変長文字列。社員名を格納するdepartment VARCHAR(50): 最大50文字の可変長文字列。部署名を格納する
Create: データを追加する(INSERT)
実行コマンド:
MariaDB [sampledb]> INSERT INTO employees (name, department) VALUES ('田中太郎', '開発部');
MariaDB [sampledb]> INSERT INTO employees (name, department) VALUES ('山田花子', '営業部');
MariaDB [sampledb]> INSERT INTO employees (name, department) VALUES ('鈴木一郎', '開発部');
id は AUTO_INCREMENT なので指定する必要はありません。MariaDB が自動で 1、2、3 と番号を割り当てます。
Read: データを読み取る(SELECT)
実行コマンド:
MariaDB [sampledb]> SELECT * FROM employees;
実行結果:
+----+--------------+------------+
| id | name | department |
+----+--------------+------------+
| 1 | 田中太郎 | 開発部 |
| 2 | 山田花子 | 営業部 |
| 3 | 鈴木一郎 | 開発部 |
+----+--------------+------------+
SELECT * は全カラムを取得する指定です。特定のカラムだけ取得したい場合は SELECT name, department FROM employees; のようにカラム名を指定します。
条件を付けて絞り込むこともできます。
実行コマンド:
MariaDB [sampledb]> SELECT * FROM employees WHERE department='開発部';
実行結果:
+----+--------------+------------+
| id | name | department |
+----+--------------+------------+
| 1 | 田中太郎 | 開発部 |
| 3 | 鈴木一郎 | 開発部 |
+----+--------------+------------+
WHERE 句で条件を指定すると、該当するレコードだけが返されます。冒頭で「テキストファイルだと grep で全体を読み込む必要がある」と書きましたが、データベースはインデックスを活用して必要なレコードだけを取得できます。
Update: データを更新する
山田花子の部署を営業部から企画部に変更します。
実行コマンド:
MariaDB [sampledb]> UPDATE employees SET department='企画部' WHERE name='山田花子';
変更結果を確認します。
実行コマンド:
MariaDB [sampledb]> SELECT * FROM employees;
実行結果:
+----+--------------+------------+
| id | name | department |
+----+--------------+------------+
| 1 | 田中太郎 | 開発部 |
| 2 | 山田花子 | 企画部 |
| 3 | 鈴木一郎 | 開発部 |
+----+--------------+------------+
山田花子の部署が企画部に変わっています。UPDATE 文では WHERE 句の指定が非常に重要です。もし WHERE を書き忘れると、全レコードの department が「企画部」に上書きされます。本番環境で WHERE なしの UPDATE を実行してしまう事故は珍しくありません。UPDATE と DELETE を実行する前に、まず SELECT で対象レコードを確認する習慣をつけてください。
Delete: データを削除する
鈴木一郎のレコードを削除します。
実行コマンド:
MariaDB [sampledb]> DELETE FROM employees WHERE id=3;
削除結果を確認します。
実行コマンド:
MariaDB [sampledb]> SELECT * FROM employees;
実行結果:
+----+--------------+------------+
| id | name | department |
+----+--------------+------------+
| 1 | 田中太郎 | 開発部 |
| 2 | 山田花子 | 企画部 |
+----+--------------+------------+
id=3 の鈴木一郎が削除され、2件になりました。DELETE も UPDATE と同様に、WHERE を忘れると全レコードが削除されます。
SQL の詳しいオプションを調べたいときは、mysql --help でクライアントのヘルプを確認できます。また、MariaDB の対話モード内で HELP コマンドを使うと SQL 文のリファレンスを参照できます(例: HELP SELECT;)。
対話モードを終了します。
実行コマンド:
MariaDB [sampledb]> EXIT;
mysqldump でバックアップ
データベースのバックアップは、サーバー運用で最も重要な作業の1つです。ハードウェア障害、人為的なミス(WHERE 忘れの DELETE など)、セキュリティインシデント。どんな原因でデータが失われても、バックアップがあれば復旧できます。
mysqldump は MariaDB/MySQL のバックアップツールで、データベースの内容を SQL 文の形でファイルに出力します。
alma-main で実行:
実行コマンド:
$ sudo mysqldump -u root -pTrainingPass123 sampledb > /tmp/sampledb_backup.sql
ダンプファイルの中身を確認します。
実行コマンド:
$ head -15 /tmp/sampledb_backup.sql
実行結果:
/*M!999999\- enable the sandbox mode */
-- MariaDB dump 10.19 Distrib 10.5.29-MariaDB, for Linux (x86_64)
--
-- Host: localhost Database: sampledb
-- ------------------------------------------------------
-- Server version 10.5.29-MariaDB
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
ダンプファイルの先頭には、文字コードやタイムゾーンなどの環境設定を一時的に変更する /*!40101 ... */ 形式のコメントが並んでいます。この後に CREATE TABLE や INSERT INTO が続きます。つまり、このファイルを MariaDB に流し込めば、テーブル構造とデータをそのまま復元できます。復元の具体的な手順は第31回「バックアップと復旧」で実践します。
ファイルサイズも確認しておきます。
実行コマンド:
$ ls -lh /tmp/sampledb_backup.sql
実行結果:
-rw-r--r--. 1 developer developer 2.1K 4月 4 13:22 /tmp/sampledb_backup.sql
今回は2件のレコードしかないので 2.1K ですが、本番環境では数 GB〜数十 GB になることもあります。バックアップファイルの保管先のディスク容量にも注意が必要です。
なお、コマンドラインでパスワードを直接指定すると Warning: Using a password on the command line interface can be insecure. という警告が表示される場合があります。本番環境では ~/.my.cnf ファイルにパスワードを記述してファイルのパーミッションを 600 にする方法が一般的ですが、今回は学習目的なのでこの方法で進めます。
SHOW PROCESSLIST で接続状況を確認する
MariaDB には、現在接続中のセッション一覧を表示するコマンドがあります。
alma-main で実行:
実行コマンド:
$ sudo mariadb -u root -pTrainingPass123 -e "SHOW PROCESSLIST;"
実行結果:
Id User Host db Command Time State Info Progress
22 root localhost NULL Query 0 starting SHOW PROCESSLIST 0.000
今は自分自身の接続(SHOW PROCESSLIST を実行しているセッション)だけが表示されています。本番環境では、アプリケーションからの接続が複数表示されます。実行中の SQL が長時間かかっている場合や、接続数が異常に多い場合にこのコマンドで状況を把握します。今は雰囲気だけ把握すれば十分です。重い SQL を特定したり、接続数の問題を調査したりする場面で使うコマンドだと覚えておいてください。
やってみよう
ここまでの内容を使って、自分でデータベース操作を実践してみてください。
課題1: products テーブルを操作する
appuser で sampledb に接続し、以下の操作を行ってください。
- products テーブルを作成する(カラム:
id INT AUTO_INCREMENT PRIMARY KEY、product_name VARCHAR(100)、price INT)。文字コードはutf8mb4を指定すること - 3件以上のデータを INSERT する(商品名と価格は自由)
SELECT * FROM products;で全件を確認する- 1件の price を UPDATE で変更し、SELECT で結果を確認する
- 1件を DELETE で削除し、SELECT で結果を確認する
接続コマンド: mariadb -u appuser -pAppPass456 sampledb
課題2: mysqldump でバックアップを取得する
- EXIT で対話モードを終了する
sudo mysqldump -u root -pTrainingPass123 sampledb > /tmp/sampledb_backup2.sqlでバックアップを取得するhead -20 /tmp/sampledb_backup2.sqlでダンプファイルの中身を確認する。employees テーブルと products テーブルの両方が含まれていることを確認する
課題が完了したら、sampledb はそのまま残しておいてください。第31回のバックアップ・復旧演習で使用します。
まとめと次回予告
今回のポイントを3つにまとめます。
- MariaDB をインストールし、初期セキュリティ設定(root パスワード・匿名ユーザー削除・test DB 削除)を行った。インストール直後の初期設定を怠ると、誰でも全権限でデータベースを操作できる状態になる
- アプリ用ユーザー(appuser)を作成し、sampledb への権限だけを付与した。root で直接操作せず、最小権限のユーザーを使う設計は Linux のユーザー管理や SELinux と同じ思想
- CRUD 操作(INSERT / SELECT / UPDATE / DELETE)を実践し、mysqldump でバックアップを取得した。UPDATE と DELETE では WHERE 句の指定を忘れると全件に影響する
次回は第31回「バックアップと復旧」です。rsync、tar、mysqldump、cron を組み合わせたバックアップ運用と、実際にデータを削除してから復旧するリストア訓練を行います。今回取得した mysqldump のバックアップファイルを使って、復元の手順を体験します。
理解度チェック
以下の文が正しければ ○、誤りであれば × と答えてください。
問1: MariaDB をインストールした直後は、root パスワードが設定されていないため、初期セキュリティ設定が必要である。
問2: MariaDB のデフォルトの文字コード(character_set_server)は utf8mb4 なので、文字コードを指定せずにデータベースを作成しても日本語を正しく扱える。
問3: アプリケーションからデータベースに接続するときは、セキュリティのために root ユーザーではなく、必要最小限の権限を持つ専用ユーザーを使うべきである。
問4: UPDATE employees SET department='営業部'; を実行すると、employees テーブルの全レコードの department が「営業部」に上書きされる。
問5: mysqldump で出力されるバックアップファイルの中身はバイナリデータである。
問6: FLUSH PRIVILEGES は、mysql.user テーブルを直接変更した場合に、変更内容をメモリ上の権限情報に反映させるコマンドである。
答え: 問1 ○ / 問2 ×(デフォルトは latin1 なので、データベース作成時に CHARACTER SET utf8mb4 を明示的に指定する必要がある) / 問3 ○ / 問4 ○(WHERE 句がないため全レコードが対象になる) / 問5 ×(mysqldump の出力は SQL 文のテキストファイルであり、バイナリデータではない) / 問6 ○
新卒からプロへ — Linux エンジニア養成講座 シリーズ一覧
フェーズ1: エンジニアのいろは
フェーズ2: Linux基礎
- 第4回 Linuxとは何か+環境確認
- 第5回 SSH接続とターミナル操作
- 第6回 ファイルシステムとディレクトリ構造
- 第7回 基本コマンド(ファイル操作)
- 第8回 基本コマンド(テキスト処理・パイプとリダイレクト)
- 第9回 viエディタ
- 第10回 ユーザーとグループ管理
- 第11回 パーミッションと所有権
- 第12回 プロセス管理
- 第13回 systemd
- 第14回 シェルスクリプト入門
- 第15回 フェーズ2まとめ演習
フェーズ3: ネットワークとインフラ基盤
- 第16回 ネットワーク基礎
- 第17回 ネットワーク設定と疎通確認
- 第18回 企業ネットワークの仕組み
- 第19回 パッケージ管理
- 第20回 ファイアウォール(firewalld)
- 第21回 ボンディング/チーミング
- 第22回 VLAN
- 第23回 ログ管理
- 第24回 cron / systemd timer
- 第25回 ストレージ管理(LVM)
- 第26回 シェルスクリプト実践
- 第27回 SSH応用
フェーズ4: サーバー構築と運用
