RHEL10がリリースされたのでその概要をまとめました。
RHEL10の概要
RHEL10.0が2025年5月にリリースされました。以下Red Hat公式ページでRHEL10の詳細を確認できます。

以下のページでRHEL10の新しい機能の詳細を確認できます。
※この記事を作成している時点では日本語に対応していないのでブラウザの翻訳機能等で日本語の記事を確認します。

RHEL10のisoファイルを入手する
以下のページから、該当のCPUのアーキテクチャにあったisoファイルを入手することができます。

「Download RHEL at no-cost」という赤いボタンを押すと、「rhel-10.0-x86_64-boot.iso」などのboot.isoファイルが入手できます。boot.isoは「rhel-10.0-x86_64-dvd.iso」と比べて軽量なファイルです。

RHEL10.0のインストール
以下の記事でRHEL10.0のインストールを検証しています。インストール時の画面等を確認できます。

RHEL10のドキュメント
以下RHEL10のドキュメントです。
RHEL10のリリースノート
以下RHEL10.0のリリースノートです。RHEL10.0の詳細な仕様を確認できます。
RHEL9とRHEL10の仕様の違い
RHEL9とRHEL10での仕様の違いは以下のドキュメントから確認できます。
主な仕様の変更の違いをかいつまんで紹介します。
RHEL10はGFS2(ファイルシステム)のサポートがなくなる
クラスターのファイルシステムとして使われていたファイルシステムGFS2がRHEL10ではサポートされなくなります。ただし、RHEL7,8,9のGFS2サポートは継続されます。
Red Hat Global File System 2 (GFS2) ファイルシステムは、64 ビットの対称クラスターファイルシステムで、共有名前空間を提供し、一般的なブロックデバイスを共有する複数のノード間の一貫性を管理します。
Red Hat Enterprise Linux (RHEL) Resilient Storage Add-On は、Red Hat Enterprise Linux 10 以降ではサポートされなくなります。これには、同様にサポートされなくなった GFS2 ファイルシステムも含まれます。
PAMに関連するrpmパッケージの仕様がRHEL10から変更された
RHEL10では以下の通りPAMに関連するrpmパッケージの仕様が変更されます。
RHEL 10 では、
authselect-libs
パッケージが/etc/nsswitch.conf
と、一部の PAM 設定 (/etc/pam.d/
内のsystem-auth
、password-auth
、smartcard-auth
、fingerprint-auth
、postlogin
など) を所有するようになりました。これらのファイルの所有権は、authselect-libs
パッケージに移行されました。以前は、/etc/nsswitch.conf
はglibc
パッケージが所有し、PAM 設定ファイルはpam
パッケージが所有していました。authselect
はpam
パッケージに必要なので、アンインストールできません。
また、authselectのプロファイルはSSSDからlocalプロファイルがデフォルトになります。SSSDはそもそもプロファイルとしては削除されたという仕様になります。
Local
プロファイルが新しいデフォルトのauthselect
プロファイルとなるRHEL 10.0 で SSSD ファイルプロバイダーが削除されたため、SSSD に依存せずにローカルユーザー管理を処理するための新しい
authselect
local
プロファイルが導入されました。local
プロファイルは以前のminimal
プロファイルを置き換え、sssd
プロファイルの代わりに、新しいインストールのデフォルトのauthselect
プロファイルになります。
インプレースアップグレードをRHEL9.6からRHEL10.0に対して行った場合は「minimal」プロファイルをlocalプロファイルにし、デフォルトのプロファイルをSSSDからlocalプロファイルにするものと思われます(現在VM ware workstaion上でRHEL10.0が使えない不具合があるため現時点(2025年6月時点)で未検証)。
アップグレード中、
authselect
ユーティリティーは既存の設定をminimal
からlocal
プロファイルに自動的に移行します。
TigerVNCが廃止され、Remote Desktop Protocol (RDP) がGUIのリモート接続で使用される
TigerVNCはRHEL10では廃止され、RDPでのリモート接続をGUIで行うことができます。
グラフィカルリモートアクセスのプロトコルが VNC からリモートデスクトッププロトコル (RDP) に変更されました。RDP は信頼性が高く暗号化された接続を提供し、暗号化に対応しておらずパスワード長にも制限があった VNC の制約を克服しています。この変更の一環として、次の新しいカーネルオプションが導入されました。
inst.rdp.username
inst.rdp
inst.rdp.password
AWSなどのRHEL10では/bootディレクトリが削除される
RHEL10では、AWSなどでRHELを使用する場合/bootが存在しません。
RHEL 10 ディスクイメージで、事前ビルドされたディスクイメージの
/boot
パーティションがなくなるAWS や KVM などのディスクイメージに個別の
/boot
パーティションがなくなりました。これにより、次の点が向上します。
RHEL8まで採用されていたifcfg 形式の定義ファイルが非対応に
RHEL8では、 /etc/NetworkManager/system-connections/
にifcfg 形式のネットワーク設定の定義ファイルが保存されていました。
RHEL9から/etc/sysconfig/network-scripts/
にkeyfile形式のファイルが作られ、こちらのファイルでネットワークの設定をOSが優先的に読み込む形へ変更されました。
RHEL9までは、RHEL8のifcfg形式のファイル、RHEL9からのkeyfile形式のファイル、どちらでもネットワークの設定を反映できましたが、RHEL10からはRHEL9で登場したkeyfileのみに対応します。
ifcfg 形式のネットワーク設定ファイルのサポートが削除される
RHEL 9.0 以降、RHEL は新しく作成されたネットワーク設定をキーファイル形式で
/etc/NetworkManager/system-connections/
ディレクトリーに保存しました。以前から/etc/sysconfig/network-scripts/
ディレクトリーに古い ifcfg 形式で設定が保存されていた接続は、中断されることなく動作し続けました。ただし、RHEL 10 リリースでは、ifcfg 形式ベースのネットワーク設定ファイルのサポートが削除されました。
RHEL10デフォルトでcompat-openssl11 がインストールされていない
Oracle Databaseのインストール時に必要なopensslがRHEL10ではデフォルトでインストールされていません。アップストリーム(Fedora、RHELの検証用ディストリビューションの環境)でメンテナンスされていないとのことなので、より新しいopensslのバージョンが必要な可能性があります(要検証、現在VM ware workstaion上でRHEL10.0が使えない不具合があるため、今後本サイトで検証結果を掲載します)。
compat-openssl11
が削除されるOpenSSL 1.1 の互換性ライブラリー
compat-openssl11
は、RHEL 10 から削除されました。OpenSSL 1.1 はアップストリームでメンテナンスされなくなりました。OpenSSL TLS ツールキットを使用するアプリケーションは、バージョン 3.x に移行する必要があります。
RHEL10デフォルトの状態だとTLSでRSA鍵が使えない
RHEL10インストール時のDEFAULT 暗号化ポリシーではTLSでRSA鍵を使用することができなくなりました。
DEFAULT
暗号化ポリシーが RSA 鍵交換による TLS 暗号を拒否するRSA 鍵交換を使用する TLS 暗号は、RHEL 10 の
DEFAULT
システム全体の暗号化ポリシーでは受け入れられなくなりました。これらの暗号は完全な Perfect Forward Secrecy を提供しないため、Elliptic-curve Diffie-Hellman (ECDH) 鍵交換などの他の鍵交換を使用する暗号ほど安全であるとは考えられていません。
RSA鍵をどうしても使う必要がある場合はシステム全体の暗号化ポリシーをLEGACY(レガシー)に設定するなどの対応が必要です。
レガシーシステムとの相互運用性のために RSA 鍵交換が必要な場合は、LEGACY システム全体の暗号化ポリシーを使用するか、カスタムサブポリシーを適用することで、再度有効化できます。
RHEL10ではSHA-1が完全に無効なものと思われる
RHEL9では、update-crypto-policies --set DEFAULT:SHA1
コマンドを入力することで何とかSHA-1を有効化することができていましたが、RHEL10からはその方法でもSHA-1が使えなくなります。
その他にもTLS(SSLのことと思ってもらって問題ない、ブラウザでサイトに接続するときのhttpsのSの部分)でもSHA-1が無効など原則RHEL10ではSHA-1が無効になったものと思われます。
LEGACY
暗号化ポリシーが TLS での SHA-1 署名を許可しないRHEL 10 の
LEGACY
システム全体の暗号化ポリシーでは、TLS コンテキストで SHA-1 を使用する署名の作成または検証は許可されなくなりました。したがって、OpenSSL 以外のライブラリーは、ユースケースに関係なく、SHA-1 を使用する署名を受け入れたり作成したりできなくなる可能性があります。システムがLEGACY
の場合、またはこの機能がカスタムサブポリシーで再度有効になっている場合、OpenSSL は TLS に使用されない SHA-1 を使用する署名を引き続き受け入れます。
SHA1
サブポリシーが削除される
update-crypto-policies --set DEFAULT:SHA1
コマンドを入力した後に、DEFAULT
システム全体の暗号化ポリシーで署名の作成と検証に SHA-1 アルゴリズムを使用することを許可していたSHA1
サブポリシーは、RHEL 10 では使用できなくなりました。
OpenSSL が TLS の
SECLEVEL=2
で SHA-1 を許可しなくなるRHEL 10 では、OpenSSL は TLS の
SECLEVEL=2
で SHA-1 アルゴリズムを受け入れません。シナリオで TLS 1.0 または 1.1 を使用する必要がある場合は、明示的にSECLEVEL=0
を設定し、LEGACY システム全体の暗号化ポリシーに切り替える必要があります。LEGACY ポリシーでは、TLS 外部の署名で SHA-1 を使用するアプリケーションは引き続き動作します。
余談ですが、TLSがSHA-1を使用している場合はブラウザに警告が出るため、実運用や設計ではTLSのSHA-1について考慮する必要は基本的にありません。これはテストや構築の段階でTLSがSHA-1であった場合にブラウザに警告が出てそこでTLSをSHA-1で使用することが不都合であることに気が付くためです。また、明示的に設定をしない限りは、TLSはSHA-2などの暗号化アルゴリズムを使用するはずです。
マイクロソフトでは、
2017 年 2 月 14 日 (米国時間)~~2017 年中旬 ~~ 2017 日 5 月 9 日 (米国時間) より、SHA-1 の TLS サーバー証明書を利用するウェブサイトを、Microsoft Edge および Internet Explorer 11 で閲覧した場合、信頼しないサイトとして警告を表示します。
パッケージインストール時にNSSではなく、ローカルの/etc/passwdと/etc/groupを参照する
パッケージインストール時にrpmコマンドはNSS(/etc/nsswitch.conf)を参照せず/etc/passwdと/etc/groupを参照します。
ユーザー名とグループ名の解決が厳密にローカルになる
パッケージをインストールするときに、RPM は、Name Service Switch (NSS) を使用するのではなく、ローカルシステムの
passwd(5)
とgroup(5)
ファイルからそれぞれユーザーとグループに関する情報を取得するようになりました。
RHEL9からRHEL10へのアップグレード
RHEL9.6からRHEL10.0へはインプレースアップグレードに対応しています。インプレースアップグレードはシステム上の RHEL9.6を RHEL 10.0 に置き換える処理です。