RHEL9サーバー構築の初期設定手順まとめ

RHEL9 サーバー構築では、インストール直後に「更新できる状態か」「時刻と日本語」「ネットワークとファイアウォール」「共有ストレージの自動マウント」を順番に固めると、後工程のトラブルが減ります。
本記事は、NFS／NTFSの自動マウント、IPv6無効化、タイムゾーンと日本語、dnf更新、firewalldによるSSH接続元制限、DNFが使えないときの調査（サブスクリプション登録済みを含む）を、構築順にまとめた実務チェックリストです。

コマンドはroot、またはsudo付きで実行してください。
CPUアーキテクチャ（x86_64／aarch64）や、直接CDNかSatellite経由かでリポジトリIDや到達経路が変わる点にも触れます。

前提と推奨する作業順

対象は、RHEL 9をインストール済みのサーバーです。
ネットワーク疎通とroot権限があることを前提にします。

推奨する順番は次のとおりです。
依存関係の都合で、お題の箇条書きとは前後しますが、実務ではこの順が安全です。

1. 環境確認（版・アーキテクチャ・NIC）
2. DNF不通の切り分けとサブスクリプション／リポジトリ整備
3. システムの更新（dnf upgrade）
4. タイムゾーンと日本語環境
5. IPv6の無効化（必要時）
6. firewalldでSSH接続元を制限
7. NFSクライアントと自動マウント
8. NTFSドライブのマウントと自動マウント

まず現状を確認します。

cat /etc/redhat-release
uname -m
hostnamectl
ip -br a
nmcli connection show

uname -mがx86_64かaarch64かで、後述のリポジトリ名が変わります。
接続名は環境ごとに異なるため、nmcli connection showのNAME列を控えてください。

DNFリポジトリが使えないときの原因調査

登録済みでもDNFが失敗するケースは珍しくありません。
「未登録だから登録する」だけに止まらず、次の順で原因を固定します。

調査の順番（固定）

1. 疎通：CDN／Satellite／プロキシへ届くか
2. 登録状態：subscription-manager identity／status
3. RHSMから見えるリポジトリ：subscription-manager repos --list
4. DNFから見えるリポジトリ：dnf repolist --all
5. manage_reposやアーキテクチャ不一致、Satelliteのコンテンツビュー

# 1) 登録状態
subscription-manager identity
subscription-manager status

# 2) RHSM側のリポジトリ一覧
subscription-manager repos --list

# 3) DNF側の有効／無効
dnf repolist
dnf repolist --all

# 4) RHSMがredhat.repoを生成するか
grep -E '^manage_repos' /etc/rhsm/rhsm.conf
ls -l /etc/yum.repos.d/

未登録の場合

未登録なら、公式どおりSubscription Managerで登録します。
登録後にプールのアタッチが必要な環境もあります。

subscription-manager register
# 必要なら
subscription-manager list --available --all
subscription-manager attach --pool=<pool_id>

登録済みなのにリポジトリが空の場合

よくあるのは、BaseOS／AppStreamが無効、またはmanage_repos = 0でredhat.repoが生成されないケースです。
アーキテクチャに合わせて有効化してください（例はx86_64）。

# manage_repos が 0 なら 1 に戻す（CDN利用時）
subscription-manager config --rhsm.manage_repos=1

# x86_64 の例
subscription-manager repos \
  --enable=rhel-9-for-x86_64-baseos-rpms \
  --enable=rhel-9-for-x86_64-appstream-rpms

# aarch64 の例
# subscription-manager repos \
#   --enable=rhel-9-for-aarch64-baseos-rpms \
#   --enable=rhel-9-for-aarch64-appstream-rpms

dnf clean all
dnf makecache
dnf repolist

Satellite配下では、アクティベーションキーやコンテンツビューにBaseOS／AppStreamが含まれていないと、登録済みでも404や「リポジトリなし」になります。
クライアント側だけで直せないときは、Satellite側の割り当てを確認してください。

リポジトリの有効化は、Subscription Managerのrepos操作が正本です。

システムの更新

リポジトリが生きていれば、システムの更新を行います。
RHEL 9ではdnf upgradeが基本です。

dnf check-update
dnf upgrade -y
# カーネルが更新された場合は再起動が必要
needs-restarting -r
# または
reboot

カーネルやglibcなど基盤パッケージが入ったあとは再起動してください。
needs-restarting -r（yum-utils／dnf-utils系）で再起動要否の目安を確認できます。

タイムゾーンと言語・日本語環境

ログや証明書期限の解釈を誤らないよう、タイムゾーンをAsia/Tokyoに合わせます。
日本語メッセージが必要なら、言語パックを入れてからロケールを変更します。

# タイムゾーン
timedatectl list-timezones | grep -i tokyo
timedatectl set-timezone Asia/Tokyo
timedatectl

# 日本語ロケール（未導入なら言語パック）
dnf install -y glibc-langpack-ja langpacks-ja
localectl list-locales | grep -i ja
localectl set-locale LANG=ja_JP.UTF-8
# コンソールで日本語キーボードを使う場合の例
localectl set-keymap jp106
localectl status
cat /etc/locale.conf

timedatectl／localectlの変更は即時反映され、再起動は不要です。
すでに開いているSSHセッションは、再ログイン後に新しいLANGが効くことがあります。

公式の基本環境設定（日時・ロケール）も参照してください。

IPv6の無効化

社内ポリシーでIPv4のみ運用する場合は、IPv6を接続単位で無効化します。
RHEL 9公式はNetworkManagerのipv6.method disabledを推奨し、これで対応するsysctlも合わせて設定されます。

# 接続名を確認（例: ens192）
nmcli connection show

nmcli connection modify ens192 ipv6.method disabled
nmcli connection up ens192

# 確認：inet6 が出ないこと
ip address show ens192
cat /proc/sys/net/ipv6/conf/ens192/disable_ipv6
# 期待値: 1

再起動は不要です。
nmcli connection upで反映されます。
sysctlだけを書いても、NetworkManagerが上書きしてIPv6が戻ることがあるため、接続プロファイル側の設定を優先してください。

IPv6を止めると、IPv6専用のDNSや監視、一部クラウドメタデータ経路に影響することがあります。
必要なサービスがIPv4で疎通することを確認してから本番適用してください。

firewalldでSSH接続元を制限する

firewalldを有効にするだけでなく、SSHを特定の管理セグメントだけに絞ります。
設定ミスで自分を締め出すと復旧が大変なので、必ずコンソール／アウトオブバンドが使える状態で実施してください。

現状確認

systemctl enable --now firewalld
firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --list-all

リッチルールで接続元を許可し、汎用sshを外す

先に許可ルールを追加し、動作確認してから、ゾーン全体へのsshサービス許可を外します。
例では管理網192.168.10.0/24のみ許可します。

# 1) 許可（永続）
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="ssh" accept'

# 2) 反映
firewall-cmd --reload

# 3) 許可元から別セッションでSSHできることを確認してから、汎用sshを削除
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# 確認
firewall-cmd --list-rich-rules
firewall-cmd --list-services

切り戻しは、汎用sshを戻すか、リッチルールを削除します。

# 切り戻し例
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.10.0/24" service name="ssh" accept'
firewall-cmd --reload

再起動は不要です。
firewall-cmd --reloadで反映されます。
既存のSSHセッションは切れにくいですが、新規接続の検証は必ず別端末から行ってください。

NFSクライアントの導入と自動マウント

共有ホームやアプリデータをNFSで受ける場合は、NFSクライアント（nfs-utils）を入れ、/etc/fstabで起動時マウントします。
ネットワーク待ちが必要なため、オプションに_netdevを付けると、ネットワーク未準備での起動ハングを避けやすいです。

dnf install -y nfs-utils
systemctl enable --now rpcbind
# NFSv3利用時など、環境に応じて rpcbind が必要

mkdir -p /mnt/nfs-data
# 手動マウントで疎通確認
mount -t nfs nfs-server.example.com:/export/data /mnt/nfs-data
ls /mnt/nfs-data
umount /mnt/nfs-data

/etc/fstabへ追記する例です。

# /etc/fstab
nfs-server.example.com:/export/data  /mnt/nfs-data  nfs  defaults,_netdev,nofail  0  0

systemctl daemon-reload
mount /mnt/nfs-data
findmnt /mnt/nfs-data
# 起動時マウントの確認は再起動後に
# reboot
# findmnt /mnt/nfs-data

nofailはNFSサーバー不通でもブートを継続したいときに有効です。
必須マウントなら外し、監視で障害検知する運用でも構いません。

オンデマンドにしたい場合は、x-systemd.automountをオプションに追加する方法もあります。
常時マウントとオンデマンドの違いは、公式の「オンデマンドマウント」章を参照してください。

NTFSドライブのマウントと自動マウント

Windows由来の外付けHDDなどを読む場合は、NTFS対応パッケージが必要です。
RHEL標準リポジトリには含まれないことが多く、EPELのntfs-3gを使うのが一般的です。

# EPEL の有効化（例）
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install -y ntfs-3g

# デバイスとUUIDの確認
lsblk -f
blkid

手動マウントで読み書きを確認してから、fstabへ落とします。
デバイス名（/dev/sdb1）は差し替わりやすいので、UUIDを使います。

mkdir -p /mnt/ntfs-data
mount -t ntfs-3g /dev/sdb1 /mnt/ntfs-data
ls /mnt/ntfs-data
umount /mnt/ntfs-data

# /etc/fstab（UUIDは環境の値に置換）
UUID=0123456789ABCDEF  /mnt/ntfs-data  ntfs-3g  defaults,nofail  0  0

systemctl daemon-reload
mount /mnt/ntfs-data
findmnt /mnt/ntfs-data

Windowsの高速スタートアップが有効だと、読み取り専用になることがあります。
書き込みが必要なら、Windows側で完全シャットダウンしてからマウントしてください。

永続マウントの一般手順（UUID・daemon-reload）は、公式の永続マウント章が参考になります。

NFSとNTFSの自動マウントで混同しやすい点

同じ「自動マウント」でも、依存するものが違います。
トラブル時は次の対比を先に見ると切り分けが速いです。

項目	NFS	NTFS
主な依存	ネットワーク・サーバ側export	ローカルブロックデバイス・FUSE
パッケージ	nfs-utils	ntfs-3g（多くはEPEL）
fstabの識別子	server:/path	UUID=...（推奨）
推奨オプション例	_netdev（必要ならnofail）	defaults（外付けならnofail）
再起動要否	fstab検証はmountで可。起動時確認は再起動	同様

NFSに_netdevを付け忘れると、ネットワーク前にマウントを試みて起動が遅延することがあります。
NTFSにサーバ名を書く、NFSにUUIDだけを書く、といった取り違えにも注意してください。

確認チェックリストと再起動の要否

作業	確認コマンド例	再起動
DNF／リポジトリ	dnf repolist	不要
システム更新	needs-restarting -r	カーネル等なら必要
タイムゾーン／日本語	timedatectl／localectl	不要（再ログイン推奨）
IPv6無効化	ip a（inet6なし）	不要
firewalld SSH制限	firewall-cmd --list-rich-rules	不要（reload）
NFS／NTFS fstab	findmnt／再起動後の自動マウント	起動時確認時のみ

まとめ

RHEL9のサーバー構築は、DNFが使える状態を先に固め、更新・日本語と時刻・ネットワーク方針・SSH制限・共有ストレージの順で進めると手戻りが少ないです。
NFSはネットワーク依存、NTFSはローカルデバイスとドライバ依存、と切り分けを分けて考えることが要点です。

firewalldの接続元制限は、許可ルール追加→別経路で疎通確認→汎用ssh削除、の順を守ってください。
DNF不通は「未登録」だけでなく、登録済みでもリポジトリ無効・manage_repos・アーキテクチャ差・Satellite側欠落を同じ順番で疑うと、原因が早く見つかります。