Rocky Linux 9 — 新サーバで最初にやるシステムアップデート

公開: 2026-05-28 約6分 rocky-linux dnf サーバ構築セキュリティ

新しい VPS を借りて SSH ログインできたら、何より先にシステムを最新化します。プロバイダが配布するOSイメージは数週間〜数ヶ月古いことが多く、その間に発見されたセキュリティ修正を取り込まないまま運用を始めるのは大きなリスクです。

本記事は Rocky Linux 9 を対象に、新規サーバで実施する初回アップデートの実務手順をまとめます。

前提条件

Rocky Linux 9.x が動作しているサーバ
root もしくは sudo 権限を持つユーザーでログイン済み
インターネット接続（リポジトリにアクセスできる状態）

1. 現状を確認する

何をアップデートする前に、まず今のサーバの状態を把握します。

bash
cat /etc/redhat-release
uname -r
uptime

出力

Rocky Linux release 9.5 (Blue Onyx)
5.14.0-503.14.1.el9_5.x86_64
 16:10:00 up 5 min,  1 user,  load average: 0.10, 0.05, 0.01

「いつアップデートが必要か」を把握:

bash
sudo dnf check-update | head -30

更新可能なパッケージが一覧表示されます（数百件あることも珍しくない）。

2. 全パッケージを一気に更新する

upgrade で全部のパッケージを最新化します。

bash

sudo dnf upgrade -y

ノート

dnf update と dnf upgrade は dnf 4 以降では同じ動作です（古い yum の慣習で update は obsolete を扱わなかったが、現在は両方とも --obsoletes がデフォルト）。upgrade で統一しておけば困りません。

進捗が流れ、最後に「Complete!」と出れば成功。サーバスペックと更新件数次第で 30 秒〜数分かかります。

3. 再起動が必要かを判定する

カーネルや glibc が更新された場合は再起動が必要です。手動で判断するのは難しいので、needs-restarting で確認します。

bash
sudo dnf install -y dnf-utils
sudo needs-restarting -r

出力

Core libraries or services have been updated since boot-up:
  * kernel

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

Reboot is required と出たら再起動。再起動が不要なら「No core libraries or services need restarting.」と表示されます。

bash

sudo reboot

注意

再起動には 30 秒〜 1 分かかります。SSH セッションは一度切れます。再接続して uname -r で新カーネルが動いていることを確認してください。

4. 不要パッケージとキャッシュを掃除

依存解決の都合で残った「もう必要のないパッケージ」を削除:

bash

sudo dnf autoremove -y

ダウンロード済みの古いキャッシュも削除（ディスク容量回復）:

bash

sudo dnf clean all

これで /var/cache/dnf/ 配下が空になります。

5. よく使う追加リポジトリ（任意）

Rocky 9 標準リポジトリだけだとカバーされないパッケージは EPEL や CRB から取れます。サーバの用途次第ですが、Webサーバ用途なら大抵入れます。

EPEL — Extra Packages for Enterprise Linux

bash
sudo dnf install -y epel-release
sudo dnf upgrade -y

CRB — CodeReady Builder（旧 PowerTools）

開発系のヘッダ・ライブラリ群が入っているリポジトリ。dnf install で「足りません」と言われる依存を解決できることが多い。

bash

sudo dnf config-manager --enable crb

6. 自動更新を設定する（任意・サーバ用途による）

「自動更新するか・しないか」はサーバ用途で大きく判断が分かれる論点です。先に判断基準を整理しておきます。

自動更新が向くケース

個人ブログ／自分しか使わないツールサーバ／検証用 VPS
短時間のダウンタイムが許容される
24時間監視運用していない

自動更新で痛い目を見やすいケース（実務でよく起きる）

ハマるのはたいてい OS 側のエラーではなく、その上で動かしているアプリケーション側が壊れるケースです。

単独サーバでの典型的な事故

更新される側	起きる現象	厄介度
PHP / Python / Node.js ランタイム	依存ライブラリの ABI ずれで特定機能だけエラー	高（サイレント）
glibc のメジャー更新	古いビルド・自前バイナリが起動不能	中（即明白）
OpenSSL のマイナー更新	TLS 挙動変化で旧ブラウザ／他社API／IoT機器から繋がらない	中（部分発生）
MariaDB / PostgreSQL のマイナー更新	クエリプラン変化で特定クエリだけ激重	高（サイレント）
nginx / Apache の更新	reload 時に active connection が瞬断	低（短時間）
WordPress / PHP 拡張	古いプラグインと非互換	中（依存次第）

複数サーバ連携での事故

構成	起きる問題
DB / Redis / Kafka レプリケーション	master ／ replica のバージョンがずれて同期停止
ロードバランス配下の web / API	同じAPIなのに当たったサーバ次第で挙動が違う
外部 API 連携	クライアントの認証方式が裏で変わり連携相手と非互換
ジョブキュー (producer ／ consumer)	バージョン違いでメッセージフォーマット不一致

これらは業務時間中に突然サービス停止として現れることが多く、有償サービスや業務 web サーバでは「更新は把握した上で計画的に適用する」のが原則です。

注意

「OS のセキュリティ更新だから安全」と思いがちですが、影響範囲はアプリケーション層まで届きます。変更内容を確認せず適用を任せるのは個人サーバ以外では避けたほうが無難です。

推奨する組み合わせ

サーバの性格	推奨設定
個人ブログ・趣味用	自動更新（security 限定）＋自動再起動
業務 web / API（単独構成）	自動更新（security 限定）、再起動は手動
業務 web / API（複数台連携）	更新そのものを手動・計画的に。`download_updates = yes` でダウンロードだけ自動化
DB / キュー / キャッシュ	完全手動。事前スナップショット必須

dnf-automatic セットアップ（個人サーバ向け・security のみ自動）

bash

sudo dnf install -y dnf-automatic

設定ファイルを編集して「security のみ自動適用」に:

/etc/dnf/automatic.confini
[commands]
upgrade_type = security        # security 更新のみ
download_updates = yes
apply_updates = yes            # 業務サーバなら no にしてダウンロードだけ
random_sleep = 300

[emitters]
emit_via = stdio

systemd timer を有効化:

bash
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic*

ヒント

業務サーバなら apply_updates = no がおすすめ。ダウンロードだけ済ませておけば、メンテナンス時間に dnf upgrade --security で即適用できます。「気づかないうちに更新されていた」を避けつつ、適用作業が高速化できる中間策です。

7. dnf history — 巻き戻しのセーフティネット

dnf は全ての更新を履歴に記録しており、ID 指定で undo できます。本番更新前に覚えておくと安心です。

bash

sudo dnf history

出力

ID     | Command line          | Date and time    | Action(s)      | Altered
-------|-----------------------|------------------|----------------|--------
    12 | upgrade -y            | 2026-05-28 16:12 | I, U           |   183
    11 | install dnf-utils     | 2026-05-28 16:11 | Install        |     1

特定のIDの更新を巻き戻す:

bash
sudo dnf history undo 12

注意

万能ではありません。バージョン依存で undo できないこともあるので、本番では事前スナップショット（VM スナップショット、btrfs subvolume snapshot 等）と併用が原則。

まとめ

現状確認

cat /etc/redhat-release / uname -r

全パッケージ更新

sudo dnf upgrade -y

再起動判定

needs-restarting -r → 必要なら sudo reboot

掃除

autoremove + clean all

任意で EPEL / 自動更新 / リポジトリ追加

用途に応じて

ここまでで「新サーバを安全な土台にする」フェーズは完了です。続いて SSH 公開鍵認証の設定 → fail2ban → firewalld と進めていけば、攻撃対象になりやすい既知の穴をひととおり塞げます。

Rocky Linux 9 — 新サーバで最初にやるシステムアップデート

1. 現状を確認する

2. 全パッケージを一気に更新する

3. 再起動が必要かを判定する

4. 不要パッケージとキャッシュを掃除

5. よく使う追加リポジトリ（任意）

EPEL — Extra Packages for Enterprise Linux

CRB — CodeReady Builder（旧 PowerTools）

6. 自動更新を設定する（任意・サーバ用途による）

自動更新が向くケース

自動更新で痛い目を見やすいケース（実務でよく起きる）

単独サーバでの典型的な事故

複数サーバ連携での事故

推奨する組み合わせ

dnf-automatic セットアップ（個人サーバ向け・security のみ自動）

7. dnf history — 巻き戻しのセーフティネット

まとめ

現状確認

全パッケージ更新

再起動判定

掃除

任意で EPEL / 自動更新 / リポジトリ追加

関連記事