タグ: RockyLinux

RHEL9系LinuxにMySQLを導入

By manualmaton

オン 2026年5月17日

カテゴリー: 未分類

RHEL9系ディストリビューション(Rocky Linux 9.7)にMySQLを導入したときのメモです。

そもそもDB（データベース）とは何なのか？

一言で言えば、「特定のルールに従って、整理整頓されたデータの集まり」です。

言うなれば「超高性能な図書館」のようなものです。
閲覧者、借りている人の帳簿を司り、膨大な本から一瞬で目的の1ページを探し出し、同時に何百人もの人が本を借りようとしても混乱が起きないように管理されています。

MySQLなどの「RDBMS」

MySQLは正確には「リレーショナルデータベース管理システム（RDBMS）」と呼ばれます。

リレーショナル（関係性）：データを「表（テーブル）」の形式で管理し、複数の表を関連付けることができます。
管理システム：データそのものではなく、データを操作・管理するためのソフトウェアのことです。

何を司るのか（役割と機能）

MySQLが担っている主な役割は、大きく分けて以下の4つです。

データの格納と検索（CRUD）
- データの登録（Create）、参照（Read）、更新（Update）、削除（Delete）の4つを、膨大な量の中から高速に行います。
整合性の維持(つじつまを合わせる)
- 「注文データはあるのに、注文したユーザーのデータがない」といった矛盾（バグの元）が起きないよう、データの整合性を厳しく見張ります。
同時実行の制御（排他制御）
- 例えば、残り1つの商品を2人が同時にクリックした際、どちらか一方が確実に買えるように調整し、「1つしかないのに2人に売れてしまった」という事故を防ぎます。
セキュリティと権限管理
- 「この人は閲覧だけ」「この人は編集もOK」といった具合に、大切なデータへのアクセスをコントロールします。

なぜ大事なのか（存在理由）

なぜExcelファイルやテキストファイルで管理するのではダメなのでしょうか？

データの爆発に対応するため

テキストファイルだと、100万件のデータから1件を探すのに上から順に読み込む必要があり、時間がかかりすぎます。DBは「インデックス（索引）」という仕組みを持ち、瞬時にデータを見つけ出せます。

データの「信頼性」を保証するため（ACID特性）

銀行振込を想像してみましょう。

Aさんの口座から1万円引く
Bさんの口座に1万円足す

もし「1」の直後にシステムがダウンしたら、1万円が消えてしまいます。

こうならないよう、DBには「トランザクション」という仕組みがあり、「すべて成功するか、すべてなかったことにするか」のどちらかしか認めません。これが社会インフラを支える信頼性の正体です。

複数のプログラムから共有できるため

Linuxサーバー上で動く

Webサイト
スマホアプリ
管理画面

など、バラバラな入り口から入ってくる要求を、一つの窓口（MySQL）が交通整理して処理してくれます。

まとめ

MySQLは、システムにおける「記憶の番人」です。

DBとは：整理されたデータの基地。
司るもの：データの出し入れ、矛盾の防止、アクセスの交通整理。
大事な理由：膨大なデータを「速く」「正確に」「安全に」扱うため。

LinuxにDBを入れるということは、そのサーバーに「確かな記憶力」と「厳格な管理能力」を持たせるということに他なりません。

ここまで踏まえ、LinuxにDBを入れていきましょう。

インストールとディレクトリ準備

MySQLサーバーのパッケージを導入し、MySQLサービスが利用するディレクトリの権限をあらかじめ適正化。

MySQLサーバのインストール

sudo dnf install -y mysql-server

サービスの起動と初期ログイン

MySQLサービスを有効化し、初期状態でのログインを確認。

サービスの有効化と起動

sudo systemctl enable --now mysqld

初期ログイン（MySQL 8.0では初期状態はパスワードなし）

mysql -u root

rootパスワードの確定

ログイン直後にMySQLのroot顕現のパスワードを設定します。

※先ほどのDBの話に戻ります。DBは「システムのデータそのもの」を管理します。先ほどの図書館の例で言うと

利用者
所蔵されている本
その本がどこにあるか（貸し出し中か、書架か）
どのようなジャンルか、作者は？

まで全て記録されている状態です。ここで、例えば、悪意ある者が「『ハムレット』の作者は『クリストファー・マーロウ』である」としたい場合、悪意ある者はそのような行為ができてしまいます。

そのため、攻撃者はDBのroot権限を真っ先に奪います。それを防ぐためにも最初にrootパスワードを設定します。

rootユーザーに対して新パスワードを適用

ALTER USER 'root'@'localhost' IDENTIFIED BY 'Your_Strong_Password';

パスワードは自分の環境に合わせます。パスワード設定後、そのデータを適切な方法・手段・保管場所に格納してください。

権限設定

FLUSH PRIVILEGES;

コンソールから抜ける

EXIT

パスワードで入れるかを確認

mysql -u root -p

設定したパスワードでログインできることを確認します。確認後、EXITで抜けます。

セキュリティの堅牢化 (`mysql_secure_installation`)

対話型スクリプトを用い、商用・本番環境に耐えうるセキュリティ設定を一括で適用します。以下のように行ってください。

Enter password for user root:

で、先ほどのrootパスワードが聞かれます。

その後、いくつかの確認事項があるのでYで答えます。

設定項目	内容	理由
Remove anonymous users	`Yes`	誰でも接続できる穴を塞ぐため
Disallow root login remotely?	`Yes`	ローカル管理に限定し攻撃経路を遮断するため
Remove test database and access to it?	`Yes`	不要なオブジェクトの排除
Reload privilege tables now?	`Yes`	設定内容を有効化するため

失敗記録：LVM物理ボリューム縮小とディスク切り詰めの挑戦。

By manualmaton

オン 2026年5月16日

カテゴリー: Linux

注意事項

これは失敗した手順です。
なのでやってはいけないやつです。
あくまでも私の失敗したときの記録として残します。

何をやりたかったのか？

「KVMで作成したディスク(LVM)を500→200程度に切り詰めようとしたところ失敗した」。

環境

ホスト
- Rocky Linux 8.6
- KVM
ゲスト
- Rocy Linux 9.7
- シックボリュームで構築

1. ゲストOS内でのデータ整理

まず、ディスク容量を空けるために /home を削除・再作成し、使用量を削減しました。

状態: 物理ボリューム（PV）500GB に対し、中身の合計（Root+Home+Swap）を 170GB 程度まで圧縮。

2. データの「前詰め」作業（pvmove）

LVMの「末尾」にあるデータを物理的にディスクの「先頭」へ移動させました。

コマンド: sudo pvmove --alloc anywhere /dev/vda2
結果: pvdisplay -m にて、使用中セグメントが 0 ～ 73153 PE（約180GB圏内）に固まり、それ以降が FREE になったことを確認。

3. PVリサイズの試行（pvresize）

管理情報を 180GB に書き換えようと試みました。

コマンド:

sudo pvresize --setphysicalvolumesize 180G /dev/vda2

結果: cannot resize to 46079 extents as later ones are allocated により失敗。
考察: LVMの内部メタデータや、目に見えない微細なフラグが末尾に残っていた可能性。

4. ホスト側での物理コピー（dd による強行突破）

「データは前に寄せた」という事実に基づき、ホスト側から物理的に180GB 分だけを切り出す作戦を敢行。

手順:

ホスト側で新LV（180GB）を作成。
dd コマンドで旧LVから 180GB 分を抽出コピー。
lvrename を使い、VMが参照するターゲットを 180GB の新ディスクにすり替え。

5. 最終結果

起動: 成功。
ログイン: 失敗。
状況: virsh console 等で応答なし。
結論: LVMおよびファイルシステムの整合性において、180GB という境界線で「管理情報の断裂」が発生。

教訓

LVMの末尾は聖域: pvmove でデータを寄せても、LVM自身の管理領域（Metadata Area）の整合性を保ったまま物理サイズを削るのは、OS稼働中や単純な dd では極めて困難である。
切り詰めるなら「外から」より「中から」: 今回のように外部から dd で削る手法は、パーティションテーブルとLVMヘッダの整合性が 1 バイトでも狂うとシステム停止に直結する。

やはり、この手のリサイズは「新たにサーバを作成し（リサイズした上で）データを流し込む」という地道な主だが一番です。

RHEL9系でMySQLのrootパスワードを忘れてしまったときの再設定メモ

By manualmaton

オン 2026年5月10日

カテゴリー: Linux

本手順は、MySQLのrootパスワードを紛失し、通常の方法でログインできなくなった場合に実施する「非常時用」のリカバリ手順です。

作業の前に

この作業は本来ならばあってはならない作業です。パスワード失念はセキュリティ事故の筆頭。ましてやWebシステムの神に等しいDBを司る通行証が消えた。なので、

事前にアカウント情報を記したファイルを保存する
適切な場所、適切なアクセス権で保管する

は必須ですが

往々にしてこの事故は起きます。なので、「マジで起きてしまった。取り敢えずの迅速な復旧」を望んでいる（つまり今回の私のような）方へのメモとなります。

この手順が笑える状況

構築中
検証作業中

のいずれかのみ。本番稼働中だったらまず笑えませんし、許可を得るための政治力・交渉力は甚大なものになります。筆者は「構築中」のパターンです。

環境

RHEL9系（RockyLinux9系）
MySQL 8

注記：RHEL 9系での注意点

従来の mysqld_safe コマンドは廃止されているため、systemctl set-environment を使用して起動オプションを制御します。
MySQL 8.0以降は skip-grant-tables モード中でも FLUSH PRIVILEGES を実行しない限り ALTER USER コマンドが受け付けられない仕様となっています。

作業影響

作業中にMySQLが止まる

これに尽きますが、「起きてしまったことは仕方ない。潔くサパッと止めてサクッと終わらせる」を心がけます。

さっくりとした手順

MySQLサービスを停止します。
認証をスキップするための環境変数をセットします。
認証スキップ状態でMySQLを起動します。
rootパスワードのリセットを行います。
認証を有効化してMySQLサービスを起動します。
リセットされたパスワードでMySQLに入れることを確認します。

MySQLサービスの停止

MySQL停止

sudo systemctl stop mysqld

MySQL停止確認

systemctl status mysld

inactive(dead)を確認します。

認証をスキップするための環境変数をセットします。

認証スキップのオプションを環境変数に一時セット

systemctl set-environment MYSQLD_OPTS="--skip-grant-tables --skip-networking"

(--skip-networkingを付けることで、作業中の外部接続を遮断し安全を確保します。)

認証スキップ状態でMySQLを起動します。

sudo systemctl start mysqld

MySQL起動確認

systemctl status mysld

active(running)を確認します。

rootパスワードのリセットを行います。

認証がスキップされている状態でログインし、権限テーブルを強制ロードしてからパスワードを書き換えます。

パスワードなしでrootログイン

mysql -u root

これでログインできたらひとまず成功です。ここからはSQL捜査を行います。

権限テーブルをリロード (ALTER USER を実行可能にするために必須)

FLUSH PRIVILEGES;

パスワードの変更を実施します。

ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_strong_password';

変更を確定して終了

FLUSH PRIVILEGES;

exit

認証を有効化してMySQLサービスを起動します。

一時的な環境変数を削除し、通常の認証が有効な状態で再起動します。

MySQLを一旦停止

systemctl stop mysqld

MySQL停止確認

systemctl status mysld

inactive(dead)を確認します。

セットした環境変数を必ず解除 (これを忘れると誰でも入れる状態が続くため重要)

systemctl unset-environment MYSQLD_OPTS

通常どおりサービスを起動

sudo systemctl start mysqld

MySQL起動確認

systemctl status mysld

リセットされたパスワードでMySQLに入れることを確認します。

mysql -u root -p

新しいパスワードでログインできたことを確認します。

まとめ

「起きないことが第一」とは言いますが、本当にくだらない理由でこういう事象は発生します。なので

起きてしまったことは潔く認める
そこから原状の復旧を目指す。
責任の追及とか誰がイモを引くかはその後で考える

の三段活用。“全裸大佐”が言う

過ちを気に病むことはない。ただ認めて、次の糧にすればいい

という「大人の特権」をフル活用しましょう。

レポジトリ一覧を確認するためのワンライナー。

By manualmaton

オン 2026年5月9日

カテゴリー: Linux

RHEL系のサーバ設定で結構重要になってくる「サーバがどのレポジトリを使っているか？

これを簡単に調べるワンライナーです。

環境

Rocky Linux 9.10

ワンライナー

echo -e "|Repo-id|Repo-name|\n|---|---|" && dnf repolist -q | awk '$1 != "repo" && NF > 1 {id=$1; $1=""; sub(/^[ \t]+/, ""); print "|" id "|" $0 "|"}'

出力結果

Repo-id	Repo-name
appstream	Rocky Linux 9 - AppStream
baseos	Rocky Linux 9 - BaseOS
epel	Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264	Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras	Rocky Linux 9 - Extras
remi-modular	Remi's Modular repository for Enterprise Linux 9 - x86_64
remi-safe	Safe Remi's RPM repository for Enterprise Linux 9 - x86_64
zabbix	Zabbix Official Repository - x86_64
zabbix-non-supported	Zabbix Official Repository (non-supported) - x86_64
zabbix-tools	Zabbix Official Repository (tools) - x86_64

と、このままマークダウン記事として貼り付けられるようになっています。

仕組み

1. `echo -e "|Repo-id|Repo-name|\n|---|---|"`

Markdown形式の表の「見出し」を無理やり作っている部分です。

echo -e: 「バックスラッシュ記法」を有効にするオプションです。
\n: これがあることで、1行目の見出しと2行目の区切り線（|---|---|）の間で改行されます。

2. `dnf repolist -q`

システムのレポジトリ一覧を取得するコマンドです。

repolist: 有効なレポジトリの ID と名前を表示します。
-q (quiet): 「メタデータの期限切れ確認」などの余計なメッセージを非表示にし、純粋なリストの結果だけを出力します。

3. `awk '$1 != "repo" && NF > 1 { ... }'`

受け取ったテキストを1行ずつ加工しています。

要素	意味
`$1 != "repo"`	1番目の項目（Repo-id）が "repo" という文字列ではない行だけを処理する（見出し除外）。
`NF > 1`	項目の数（Number of Fields）が1つより多い行＝空行などを除外。
`id=$1`	1番目の項目（Repo-id）を変数 `id` にキープ。
`$1=""`	1番目の項目をデータから消去。これで残りの `$0`（行全体）が Repo-name だけになります。
`sub(/^[ \t]+/, "")`	1列目を消した後に残ってしまう「先頭の空白」を削除して綺麗にします。
`print "\|"...`	最後に、Markdownの枠組み `\|` で囲って出力します。

まとめ

echo で表の見た目を作り、
dnf でデータを静かに（-q）呼び出し、
awk で「いらない行（repo）」を捨てつつ、1列目（ID）とそれ以降（Name）をバラバラにして | で挟み直す。

という流れになっています。

Linuxサーバ、稼働中のサービスのバージョンを確認するワンライナー。

By manualmaton

オン 2025年12月24日

カテゴリー: Linux

概要

Linuxサーバの構築時に非常に面倒で厄介な「動いているサービス(systemctl status hoge.service でenabledになっているもの)だけを取り出し、表に転記するという作業が

限りなく単調で
とてもミスが多い

重箱の隅をつつくような作業を一発で解消するワンライナーの紹介です。

前提

RHEL系Linuxで動きます。(筆者環境Rocky Linux)

ワンライナー

※これは

sudo su

としてから入力した方が無難です。(パッケージによっては一般的権限では見られないため)

 { echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"; systemctl list-unit-files --type=service --no-legend | awk '{print $1}' | grep -v '@\.service$' | xargs -r systemctl show -p FragmentPath | sed 's/^FragmentPath=//' | grep '^/' | sort -u | xargs -I {} sh -c 'if rpm -qf "{}" >/dev/null 2>&1; then rpm -qf "{}" --qf "| %{NAME} | %{VERSION}-%{RELEASE} |\n"; else echo "| $(basename "{}") | (not owned by any package) |"; fi' | sort -u; }

スクリプトの解説

このコマンドは大きく分けて「ヘッダーの出力」「サービスファイルのパス特定」「パッケージ情報の取得と整形」の3つのフェーズで動いています。

1. 表のヘッダーを作成

{ echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"; ... }
- 最初にMarkdown形式の表の1行目（項目名）と2行目（区切り線）を出力します。
- 全体を { } で囲むことで、ヘッダーと後の実行結果を一つの出力ストリームとしてまとめています。

2. サービス一覧からファイルパスを特定

ここからがメインのパイプラインです。

systemctl list-unit-files --type=service --no-legend
- システム上の全サービスユニットを表示します。--no-legend でヘッダー行を省きます。
awk '{print $1}'
- 出力結果から1列目（サービス名）だけを抜き出します（例: sshd.service）。
grep -v '@\.service$'
- インスタンス化されたユニット（user@.service など）を除外します。これらは実ファイルが少し特殊なためです。
xargs -r systemctl show -p FragmentPath
- 各サービスに対して、その定義ファイル（ユニットファイル）がディスク上のどこにあるか（FragmentPath）を取得します。
sed 's/^FragmentPath=//'
- 出力に含まれる FragmentPath= という文字列を削除し、純粋なパス名だけにします。
grep '^/'
- 空行や無効なパスを除外し、/ から始まる絶対パスのみを残します。
sort -u
- 重複したパスを削除します。

3. RPMによるパッケージ照会と整形

特定されたファイルパスを一つずつ RPM データベースと照合します。

xargs -I {} sh -c '...'
- 各パス（{}）に対して、シェルスクリプトを実行します。
if rpm -qf "{}" >/dev/null 2>&1; then ...
- そのファイルが RPM パッケージによって管理されているかを判定します。
- 管理されている場合: rpm -qf を使い、パッケージ名とバージョンを Markdown の行形式 | 名前 | バージョン | で出力します。
- 管理されていない場合: （手動で作成したサービスなど）「(not owned by any package)」と出力します。
sort -u（最後）
- 最終的なリストをソートし、重複を排除して綺麗に並べます。

実行結果のイメージ

コマンドを実行すると、以下のような結果が得られます。

ソフトウェア名	バージョン
chrony	4.1-3.el9
openssh-server	8.7p1-10.el9
my-custom-script.service	(not owned by any package)
systemd	250-6.el9

このワンライナーの利点

徹底した合理性。
- なにせ「目視確認」という手段が排除されます。一切のヒューマンエラーがなくなります。
一覧性と整合性。
- 「最新の情報を全て表示せよ」という要求に対してもコマンドを叩くだけで済みます。
再利用性
- これが一番大きいです。2020年代ITで最も使いやすいMarkdownのテーブル形式。そのため、
  - Redmine
  - VS Code
  - Notion
    などにいくらでも反映可能。そして、一度テーブルにしてしまえばExcelへの転記も一発です。

まとめ

「ウサギとカメの寓話」は、コツコツやる者が強いパターンではありますが、「60分の道を頑張って55分に縮めるよりも、30分かけて『1分で終わる手段を考える』」方が、本当の「タイムパフォーマンス」だと思った次第です。

備考

Ubuntuサーバでも、このようにすれば動きます。

{
  echo -e "| ソフトウェア名 | バージョン |\n| --- | --- |"
  # 1. サービスファイルのパス一覧を取得
  systemctl list-unit-files --type=service --no-legend | \
  awk '{print $1}' | \
  grep -v '@\.service$' | \
  xargs -r systemctl show -p FragmentPath | \
  sed 's/^FragmentPath=//' | \
  grep '^/' | \
  sort -u | \
  # 2. 1行ずつ読み込んで処理（whileループでシェル起動を最小化）
  while read -r path; do
    # dpkg-query -S は dpkg -S より高速で安定しています
    res=$(dpkg-query -S "$path" 2>/dev/null)
    if [ $? -eq 0 ]; then
      pkg=$(echo "$res" | cut -d: -f1)
      # 複数のパッケージがヒットする場合があるため、最初の1つを取得して詳細表示
      dpkg-query -W -f="| \${Package} | \${Version} |\n" "${pkg%%,*}"
    else
      echo "| $(basename "$path") | (not owned by any package) |"
    fi
  done | sort -u
}

RHEL系Linux(Rocky Linux)でDockerのビルド領域変更

By manualmaton

オン 2025年12月10日

カテゴリー: Linux

Dockerならではの問題に対処したのでメモを残します。

背景と課題

RHEL / Rocky Linux 9 環境のGPUサーバーにおいて、Dockerビルド（大規模LLMモデルの生成など）を実行した際、ルートパーティション（/）の使用率が100%に達する事象が発生しました。

原因: Dockerはデフォルトで /var/lib/docker（ルート配下）にイメージやビルドキャッシュを保存します。
環境: ルート領域は70GB程度ですが、/home 領域には数TBの空きがります。
対策: パーティションリサイズ（LVM操作）はリスクが高いため、Dockerのデータ保存先（data-root）を /home 配下へ物理的に移行して解決します。

さっくりとした手順

現状を確認し、サービスを停止します。
Dockerの移行ディレクトリを作成します。
rsyncを用いて安全にデータを移行します。
Dockerの設定ファイルを変更します。
Dockerサービスの再起動を行います。
設定変更を確認します。

現状の確認とサービスの停止

まず、現在のDocker設定とディスク使用量を確認し、Dockerサービスを停止します。

Dockerの保存先確認

docker info | grep "Docker Root Dir"

→ （デフォルトは /var/lib/docker）

Dockerサービスを停止します。

sudo systemctl stop docker docker.socket

Dockerサービスの停止を確認します。

systemctl status docker

inactive(dead)を確認します。

移行先ディレクトリを作成します。

大容量領域（今回は /home 配下）に新しい保存用ディレクトリを作成します。

ディレクトリ作成

sudo mkdir -p /home/docker/data

データの移行（最重要）

既存のイメージやコンテナデータを保持するため、rsync を用いてデータを同期します。
※ cp コマンドよりも、権限やタイムスタンプを正確に保持できる rsync を推奨します。
※ rsyncはRocky9に最初から入っているコマンドです。

/var/lib/dockerの中身を、新ディレクトリへコピー

sudo rsync -aqxP /var/lib/docker/ /home/docker/data/

-a: アーカイブモード（権限等を保持）
-x: ファイルシステム境界を越えない
注意: コピー元のパス末尾に / を付けることで、ディレクトリそのものではなく「中身」を転送先に展開します。

設定ファイルの変更 (daemon.json)

ファイルのバックアップを取ります。（凄く重要）

何かあったときの切り戻しのため。特に、後述するjsonの編集をミスると地獄行きの通過駅無しの特急が待っています。

sudo cp -pi /etc/docker/daemon.json /path/to/backup/directory/daemon.json.$(date +%Y%m%d)

ファイルのバックアップをdiffで取ります。

sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

一般ユーザが読み取れないディレクトリ構造も考慮して、念のためsudoをつけます。

→ エラーがなければバックアップ成功。ここでコピー元とコピー先を逆にしているのは編集後のdiffを取るためです。

Dockerに新しい保存先を認識させるため、/etc/docker/daemon.json を編集します。(エディタは宗教問題のため、自分の教義・信仰に沿ったものを利用してください）

変更例:
data-root オプションを追記します。
JSON形式のため、行末のカンマ（,）の有無に注意してください。

{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "data-root": "/home/docker/data"
}

編集後の差分をdiffで確認します。

sudo diff -u /path/to/backup/directory/daemon.json.$(date +%Y%m%d) /etc/docker/daemon.json

以下のようになっていることを確認します。

-     "data-root": "/var/lib/docker"
+     "data-root": "/home/docker/data"

サービスの起動と確認

Dockerを起動し、設定が反映されているか確認します。

Dockerサービスを起動します。

sudo systemctl start docker

Dockerサービスの起動を確認します。

systemctl status docker

active(running)を確認します。

設定反映の確認

docker info | grep "Docker Root Dir"

=> Docker Root Dir: /home/docker/data となっていれば成功です。

不要データの削除（任意）

動作確認後、元の /var/lib/docker を削除または退避させて、ルートパーティションの空き容量を回復させます。

安全のため、バックアップを取るか慎重に削除してください。この作業を行うときは深呼吸を3回ほど行い、飲み物を飲むなどして落ち着いてから行いましょう。

sudo rm -rf /var/lib/docker

結果

本対応により、ルートパーティションの圧迫が解消されました。

Before:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G   70G   20K 100% /

After:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   70G  6.0G   65G   9% /
/dev/mapper/rl-home  6.9T  198G  6.7T   3% /home

トラブルシューティング

SELinux: 起動に失敗する場合、SELinuxが非標準ディレクトリへのアクセスをブロックしている可能性があります。一時的に setenforce 0 で切り分けを行うか、適切なコンテキストを設定してください。
JSON構文エラー: daemon.json の記述ミス（カンマ忘れなど）があるとDockerが起動しません。編集後は慎重に確認を行いましょう。

RHEL系LinuxサーバにRTX 6000を認識させる。

By manualmaton

オン 2025年12月7日

カテゴリー: Linux

※昨今のトレンドである「GPU前提のLinuxサーバ」つまり、AI環境に必須の

データセンタークラスのGPU
それをRHEL系Linuxに認識させ
更にDockerというトレンドでも動かす

という難易度が高く――そして、インフラ屋にとって極上の素材を得る経験がありました。

そのときのメモです。（氷見の本マグロを捌くことになった調理師のような気分でした）

“逸般”の誤家庭的な環境

まず、これを一般家屋に置くと言うことはないでしょう。

OS:
- Rocky Linux 9.x (Minimal Install)
Kernel:
- 5.14.0-x (RHEL 9 Standard)
GPU:
- NVIDIA RTX 6000 Ada Generation x 1
  - →2025/12/06時点でもちょっとした軽自動車が買えるやつです
Driver:
- NVIDIA Driver 590.xx (Open Kernel Module)
Container Runtime:
- Docker CE 27.x + NVIDIA Container Toolkit

前提環境の整備

OSインストールを行います。(Rocky Linux Minimal)
ネットワークの設定を行います。
dnf updateを済ませます。

NetworkManagerによるネットワーク設定

固定IP化および自動接続設定を行う。

接続プロファイル名の正規化 (デバイス名と合わせる)

sudo nmcli connection modify "Wired connection 1" connection.id eno2

固定IP設定

sudo nmcli connection modify eno2 ipv4.addresses xx.xx.x.x/16

sudo nmcli connection modify eno2 ipv4.gateway Gateway IP

sudo nmcli connection modify eno2 ipv4.dns "DNS1 DNS2"

sudo nmcli connection modify eno2 ipv4.method manual

sudo nmcli connection modify eno2 connection.autoconnect yes

→ これをやっておかないと、再起動したときにNW設定が消えます。

設定反映

sudo nmcli connection up eno2

システム更新とリポジトリ適用

RHEL 9 系でサードパーティ製パッケージを入れるため、これは必須です。特に、CRB (CodeReady Builder) の有効化を忘れると依存解決ができず、高性能GPUを認識させることができません。

dnf全更新

sudo dnf update -y

サーバ再起動

sudo reboot

→ カーネルアップデートも含まれるため。

CRB有効化 (旧 PowerTools)

sudo dnf config-manager --set-enabled crb

EPEL導入

sudo dnf install epel-release -y

NVIDIA Driver の導入

ここまで来たらいよいよ本命。（先のマグロの例に例えると、いよいよマグロの身に刃を当てていきます）

【重要】 RTX 6000 Ada はプロプライエタリ版ドライバではなく、Open Kernel Module (open-dkms) を要求します。これに気づかずハマりかけました。

依存関係の解決とリポジトリの導入。

開発ツールの導入

sudo dnf groupinstall "Development Tools" -y

カーネルヘッダの導入

sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y

NVIDIA公式リポジトリ (RHEL9用) 追加

sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo

旧ドライバ/競合の排除

以前のインストール試行や（ハマったところ）、OSに入っているであろうGPUドライバを取り除かないと詰まります。

nvidia dkmsドライバのアンインストール

sudo dnf remove nvidia-driver kmod-nvidia-latest-dkms -y

nvidia dkmsドライバのリセット

sudo dnf module reset nvidia-driver -y

Open Kernel Module 版のインストール

dnf module機能を使って open-dkms ストリームを指定してインストール

sudo dnf module install nvidia-driver:open-dkms -y

サーバ全体を再起動してカーネルモジュールをロード

sudo reboot

ドライバ動作確認

nvidia-smi

-> `Driver Version: 590.xx / GPU Name: RTX 6000 Ada / VRAM: xxGB が表示されることを確認します。

コンテナ基盤の構築

筆者はコンテナが好みではないのですが、それはそれです。相手のオーダーに答えるのもまたお仕事。

Docker CE のインストール

ここではpodman ではなく Docker CE を採用しました。

Docker CEレポジトリ追加

sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Docker CEインストール

sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Docker 自動起動有効化

sudo systemctl enable --now docker

現在のユーザをDockerグループに加える

sudo usermod -aG docker $USER

NVIDIA Container Toolkit の導入

DockerコンテナでGPUが見えないと、せっかく「Dockerを入れろ」というオーダーが無になります。

Toolkitインストール

sudo dnf install nvidia-container-toolkit -y

Dockerランタイム設定 (daemon.jsonの更新)

sudo nvidia-ctk runtime configure --runtime=docker

Tookit/ランタイム反映

sudo systemctl restart docker

動作確認 (パススルーテスト)

コンテナ内部から GPU が見えるか確認します。

sudo docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

成功時、コンテナ内からホスト同様の nvidia-smi 結果が出力されれば動作完了です。

追加要素：最新トレンドに合わせた開発環境の用意。

言語ランタイム (Modern Runtime)の導入

OS標準を汚さず、最新の開発環境を整備する。

Node.js 22+:
- NodeSourceリポジトリより導入。これは割愛です。（どっかしら探せば出てくるので）
Python 3.12:
- Rocky Linuxは3.9。しかも、OSの核となっているプログラムなので、ソースコードを用いて altinstall (共存インストール) しないとサーバそのものが吹っ飛びます。

※実行例

開発環境導入

sudo dnf install -y openssl-devel bzip2-devel libffi-devel zlib-devel readline-devel sqlite-devel tk-devel xz-devel

ソースコードダウンロード

wget https://www.python.org/ftp/python/3.12.8/Python-3.12.8.tgz

ソースコード展開

tar xzf Python-3.12.8.tgz && cd Python-3.12.8

ソースコードconfigure(最適化オプション)

./configure --enable-optimizations

CPUコアフルに用いての高速メイク

make -j $(nproc)

altinstall

sudo make altinstall

altinstallを入れないと上述したようにサーバが吹っ飛びます。

トラブルシューティング (Tips)

以下のエラーに出くわしたときの原因と対策です。

NVRM: requires use of the NVIDIA open kernel modules:
- 原因: Ada世代のGPUに対し、従来のプロプライエタリドライバを入れたため。
- 対策: dnf module install nvidia-driver:open-dkms を使用しました。
Secure Boot:
- ドライバ導入前に BIOS/UEFI で Disabled になっていることを確認すること（署名周りのトラブル回避）。

RHEL系サーバ、実物環境下でのネットワーク設定

By manualmaton

オン 2025年12月6日

カテゴリー: Linux

はじめに

GUIが多くなったとは言え、Linuxサーバは基本的にCLI(コマンドライン)・SSH接続によるリモート操作が基本です。この、CLIの環境下でのネットワーク設定という基本のメモです。

環境とやったこと

極めてよくあるユースケースです。即ち

「サーバ実機はこれである。ひとまず組織内（社内）ネットワークにつなげ」

という指令への対処。

物理サーバ
- 今回はVPSではありません。実機です。
- その大きさ、重さを知るのもインフラ屋の醍醐味です。
Rocky Liunx 9.x
- (RHEL系フォーク、ミニマルインストール)
ローカルNWにサーバのIPを割り当てる。
NW設定を有効化する。
- 固定IP。クライアントならいざ知らず、サーバ運用は固定IPであるべきです。
- IP: 172.xx.xx.xx/16 (/16はサブネットマスク255.255.0.0を意味します)
- GW: 172.xx.254.254 (※これはあくまでも例です)
- DNSサーバ/ドメイン：ローカルで定められているもの。

さっくりとした手順

ではありますが、かなり慎重に書いています。

RockyLinuxサーバをMinimalでインストールします。
サーバコンソールに直接ログインします。
ネットワークインタフェースを確認します。
nmcliによりネットワークを設定します。
ネットワークインタフェースを有効化します。
サーバを結線してリンクアップを確認します。
最初のdnf updateを行います。

RockyLinux 9.6インストール

インストール方法については割愛。GUI無しのMinimalをインストールします。というのも、多くのサービスが入ってしまうと、自分が管理しきれない部分が増えると共に、そこが脆弱性となるからです。

また、ここでは最初からネットワークにつなぎません。設置する組織によってはLAN接続も許可制になっているパターンが極めて多いです。（IPも指定されたものを使うというのが実情でしょう）

サーバコンソールにログイン

この段階ではrootでも構いません。何せ、物理的に言葉通りの意味で切断されているのですから。

物理ネットワークの確認

vpsと違い、最初からネットワークにつながっていません。当然、IPも振られていません。なので「どのLANポートを使うか？」から始まります。

nmcli

を実行します。これはNetwork Manager Command Line Interfaceの略であり、RHELサーバの肝と言えるネットワーク設定コマンドです。（普段Ubuntuサーバを使う筆者は少々混乱しました）

筆者環境では

eno2
eno3

がありました。ここではeno2を確認していきます。

ネットワーク設定

現状確認

nmcli connection show

以下のような例が出てきます。

NAME     UUID                                  TYPE      DEVICE
eno2     UUID文字列                             ethernet  eno2
lo       UUID文字列                             loopback  lo
eno3     UUID文字列                             ethernet  eno3

この、eno2というポートを使います。

※例外

もし、もし NAME 列に Wired connection 1 とあり、DEVICE 列が eno2 ならば、次の手順で名前を変更します。

※例外時の実施- "Wired connection 1" を "eno2" にリネーム

sudo nmcli connection modify "Wired connection 1" connection.id eno2

IPとサブネット設定 (CIDR表記でスマートに)

sudo nmcli connection modify eno2 ipv4.addresses 172.xx.xx.xx/16

→ 実際に指定されたIPアドレスを入力します。このとき、二重チェックで「同一ネットワーク内にIPアドレスが無いか？ / 打ち間違いがないか？」を確認しましょう。被ってしまうと単純な破滅が待っています。

ゲートウェイ設定

sudo nmcli connection modify eno2 ipv4.gateway 172.xx.254.254

こちらも同様。別のゲートウェイを設定していないかを確認。

DNS設定

sudo nmcli connection modify eno2 ipv4.dns "DNS1 IPアドレス DNS2 IPアドレス"

→ DHCPと異なり、固定IPはDNSサーバを指定します。組織内では冗長性のため複数あるケースがほとんどです。

ドメイン設定

sudo nmcli connection modify eno2 ipv4.dns-search "組織内ドメイン"

→ 組織内ドメインで、FQDNの名前解決を効率化するため。

メソッドを手動にしてIPアドレス固定

sudo nmcli connection modify eno2 ipv4.method manual

【重要】自動接続をONにする (これを忘れると再起動後に死ぬ)

sudo nmcli connection modify eno2 connection.autoconnect yes

→ autoconnect no の状態だと、システムが再起動した後、NetworkManagerは設定ファイルは認識していますが、その接続を自発的に起動しません。つまり、何らかの事情でサーバそのものを再起動した場合、このネットワーク設定が断たれます。即ち、あらゆるネットワークから完全に切り離されます。

ネットワーク設定の有効化

ここまで来たらいよいよサーバにネットワークを認識させます。このコマンドの前に深呼吸をして落ち着きましょう。(サーバ室/データセンターからの離席を許されるならこの段階で)

再起動して設定をロード

sudo nmcli connection up eno2

IPアドレスの確認

ip addr show eno2

→ インターフェース eno2 に正しいIPアドレス、ネットマスクが割り当てられたか。

eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

ルーティングの確認

ip route

→ デフォルトゲートウェイ（外部ネットワークへの出口）が正しく設定されたか。

IPアドレスが正しくても、どこへパケットを送るか（経路情報）がなければ、ローカルネットワーク外へは通信できません。

default via  172.xx.254.254 dev eno2

などの行がないと、外部環境は無意味です。初歩的ですが非常に詰まりやすいポイントです。

DNS設定の確認

cat /etc/resolv.conf

→ ネームサーバーと検索ドメインが設定ファイルに反映されたか。

nameserver: 設定した社内のDNSサーバーのIPアドレス（例: nameserver 192.168.1.53）が正しくリストアップされているか。
もしこれらが正しく反映されていなければ、名前解決ができず、Webサイトの閲覧やホスト名でのサーバーアクセスができなくなります。

サーバの結線

上記が確認できたら、サーバという鉄の箱を「ネットワークと通信ができる」状態へと落とし込みます。ここでも、単純ながら致命的なミスが待ち構えています。

以下を確認しましょう。

LANポートの接続先と接続元は合っているか？
- 特に、LANポートの迷路とも言えるサーバ室やデータセンターではこれらを間違えると地獄が待っています。比喩的な意味では無く。
LANケーブルは断線が無いか？
- 切り分けの手間を減らします。
ストレートとクロスを間違えていないか？
- たまにありますが結構盲点です。

疎通確認

Gatewayへの Ping:ping -c 4 172.xx.254.254
- これが通れば、L2/L3（組織/社内ネットワークへの物理・論理接続）は成功しています。
DNSサーバへの Ping:ping -c 4 [DNSサーバーのIP]
- これが通れば、名前解決の準備OKです。
外の世界への Ping:ping -c 4 google.com
- これで初めて「インターネット接続完了」です。

DNFアップデート

サーバ全体のLinuxシステムを「最新の状態にする」おまじないです。

sudo dnf update -y

ここでの注意点はトラフィック。大容量のデータがこのサーバに流れます。貧弱な回線ではたちまちパンクします。

Complete!と表示されたら、

sudo reboot

で物理的に再起動します。というのも、dnfアップデートはたいがいカーネルの更新も伴うからです。

この再起動後、「先ほどのネットワーク設定が活きているか？　失われていないか？」が伴い、初めてこのネットワーク設定という初歩的な設定が完了します。

Ubuntuでプロンプトの挙動を変更(ちょいハマり-1-)。

By manualmaton

オン 2023年9月26日

カテゴリー: Linux

ちょっとハマっていること

LinuxのCUI操作で、

プロンプトの内容を「ユーザ名@ホスト名カレントディレクトリ」に変更する。
一般ユーザの場合はプロンプトを緑にして\&で表記。
rootに昇格した場合はプロンプトを赤にして#で表記。

という挙動にしています。

RockyLinuxの場合：OK

以下の内容を /etc/bashrc に組み込めばOKでした。

if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

Ubuntuの場合：NG

ところが、Ubuntu系は

上記の設定を/etc/bash.bashrcに追記してもプロンプトの動きが想定通りとならない。
source /etc/bash.bashrcと実行すると、設定が反映される。

これは相当面倒です。ログイン時に別のスクリプトか何かでこれを実行すればいいのでしょうが、新しいユーザを作成した場合など不都合が生じます。

Ubuntuでのワークアラウンド

取り急ぎ、当初の目的である「一般ユーザと特権ユーザでプロンプトの色や記号を変える」を優先させます。

ログインユーザ（一般ユーザ）の設定ファイル

~.bashrc

末尾に以下を追記します。

# 一般ユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  if [ "$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi

rootの設定ファイル

/root/.bashrc

末尾に以下を追記します。

# rootユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
fi

これで当面の問題は回避できましたが、根本的な解決には至らず。

もう少し調査が必要です。

2026年5月
月	火	水	木	金	土	日
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

タグ: RockyLinux

そもそもDB（データベース）とは何なのか？

MySQLなどの「RDBMS」

何を司るのか（役割と機能）

なぜ大事なのか（存在理由）

データの爆発に対応するため

データの「信頼性」を保証するため（ACID特性）

複数のプログラムから共有できるため

まとめ

インストールとディレクトリ準備

サービスの起動と初期ログイン

rootパスワードの確定

セキュリティの堅牢化 (mysql_secure_installation)

注意事項

何をやりたかったのか？

環境

1. ゲストOS内でのデータ整理

2. データの「前詰め」作業（pvmove）

3. PVリサイズの試行（pvresize）

4. ホスト側での物理コピー（dd による強行突破）

5. 最終結果

教訓

作業の前に

この手順が笑える状況

環境

注記：RHEL 9系での注意点

作業影響

さっくりとした手順

MySQLサービスの停止

認証をスキップするための環境変数をセットします。

認証スキップ状態でMySQLを起動します。

rootパスワードのリセットを行います。

認証を有効化してMySQLサービスを起動します。

リセットされたパスワードでMySQLに入れることを確認します。

まとめ

環境

ワンライナー

仕組み

1. echo -e "|Repo-id|Repo-name|\n|---|---|"

2. dnf repolist -q

3. awk '$1 != "repo" && NF > 1 { ... }'

まとめ

概要

前提

ワンライナー

スクリプトの解説

1. 表のヘッダーを作成

2. サービス一覧からファイルパスを特定

3. RPMによるパッケージ照会と整形

実行結果のイメージ

このワンライナーの利点

まとめ

備考

背景と課題

さっくりとした手順

現状の確認とサービスの停止

移行先ディレクトリを作成します。

データの移行（最重要）

設定ファイルの変更 (daemon.json)

サービスの起動と確認

不要データの削除（任意）

結果

トラブルシューティング

“逸般”の誤家庭的な環境

前提環境の整備

NetworkManagerによるネットワーク設定

システム更新とリポジトリ適用

NVIDIA Driver の導入

依存関係の解決とリポジトリの導入。

旧ドライバ/競合の排除

Open Kernel Module 版のインストール

ドライバ動作確認

コンテナ基盤の構築

Docker CE のインストール

NVIDIA Container Toolkit の導入

動作確認 (パススルーテスト)

追加要素：最新トレンドに合わせた開発環境の用意。

言語ランタイム (Modern Runtime)の導入

トラブルシューティング (Tips)

はじめに

セキュリティの堅牢化 (`mysql_secure_installation`)

1. `echo -e "|Repo-id|Repo-name|\n|---|---|"`

2. `dnf repolist -q`

3. `awk '$1 != "repo" && NF > 1 { ... }'`