えんでぃの技術ブログ

えんでぃの技術ブログ

ネットワークエンジニアの視点で、IT系のお役立ち情報を提供する技術ブログです。

トップ > Linux > Fedora41の変更点

Fedora41の変更点

Linux

Fedoraの変更点シリーズ

過去リリース分の記事は、以下のリンクを参照してください。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora 41のリリースノートを読んで、個人的に気になった項目をまとめます。

公式情報の見方

Fedora 41の変更点は、以下のリンクに載っています。
概要はリリースノートに、詳細情報はChange Setsのページに書いてあります。

Change Setの各サブタイトルのリンクから詳細情報に飛べるようになっています (下図赤枠部)。
詳細を知りたい時に便利なので、こちらも活用ください。

fedora_change_sets

Fedora 41の既知の問題は、以下にまとめられています。

他バージョンのFedoraについて知りたい場合は、以下のリンクを参照してください。

Release Notes & Changes

DNF5がデフォルトに

Fedora40まではDNFのバージョンが4系でしたが、Fedora41以降は5系になります。
RPMパッケージの名称もdnfからdnf5に変わります。

(DNF4)

dnf --version | head -1
# 4.19.2

ls -l /usr/bin/dnf
# lrwxrwxrwx. 1 root root 5 Mar 29  2024 /usr/bin/dnf -> dnf-3

rpm -qa | grep -P '^dnf(5|)-\d'
# dnf-4.19.2-1.fc40.noarch

(DNF5)

dnf --version | head -1
# dnf5 version 5.2.6.2

ls -l /usr/bin/dnf
# lrwxrwxrwx. 1 root root 4 Sep 20 09:00 /usr/bin/dnf -> dnf5

rpm -qa | grep -P '^dnf(5|)-\d'
# dnf5-5.2.6.2-1.fc41.x86_64

DNF5の改善点を一部抜粋します。

  • DNFプログラム本体のファイルサイズ軽量化 (コンテナ環境において、dnf関連ファイルのサイズが60%減)
  • クエリの高速化 (以下の例では実行時間が2-4秒短縮されていることがわかる)

(DNF4)

dnf clean all
# 17 files removed

# キャッシュ無し
time dnf repoquery > /dev/null 2>&1
# real  0m14.801s
# user  0m10.556s
# sys   0m0.540s

# キャッシュ有り
time dnf repoquery > /dev/null 2>&1
# real  0m2.878s
# user  0m2.692s
# sys   0m0.156s

(DNF5)

dnf clean all
# Removed 20 files, 9 directories. 0 errors occurred.

# キャッシュ無し
time dnf repoquery > /dev/null 2>&1
# real  0m10.151s
# user  0m5.554s
# sys   0m0.371s

# キャッシュ有り
time dnf repoquery > /dev/null 2>&1
# real  0m0.590s
# user  0m0.528s
# sys   0m0.095s
  • APIメソッドが変わる。古いAPIは一部廃止される (Ansibleでdnfとdnf5でモジュールが分かれている背景が理解できました)
  • UIの統合。サブコマンドやコマンドラインオプションのaliasが整備されており、新しいコマンド体系と従来のコマンドの両方をサポートする
    • 例: dnf repoquery -l <file>はdnf repoquery --files <file>のalias。DNF4の-lとDNF5の--filesはどちらも動作する
    • 詳しい説明はman dnf5-aliasesを参照

その他気づいたこととしては、以下が挙げられます。

  • manページがサブコマンド別に分割されて可読性が向上した
    • DNF4時点ではman dnfにdnf listやdnf installなどのサブコマンドが全て書かれていて縦長なmanになっていた
    • DNF5ではman dnf5-listやman dnf5-installなどサブコマンド別に分割されて見やすくなった
    • man dnf-listのように5を省略してもヒットしてくれる
  • 標準出力が細かく変更されている。dnf listを例にすると...
    • DNF4は画面横幅いっぱいに使うよう列幅が自動調整されていた。DNF5は列幅がコンパクトに (個人的にはこれが一番うれしいです)
    • DNF5はサブセクションの手前に空行が挿入されるようになった
    • 色分けが変わった。DNF4ではパッケージ名がオレンジ色と水色に塗り分けられていた (基準はわかりません)。DNF5ではインストール済みが緑、他は白とシンプルに

(DNF4)

dnf4_list

(DNF5)

dnf5_list

NetworkManagerのifcfg形式設定ファイルの提供終了

NetworkManagerの設定ファイル形式としてifcfg形式がFedora 41以降でサポートされなくなります。
以下のrpmパッケージがFedora 41以降のリポジトリでは提供されなくなりました。

  • NetworkManager-initscripts-ifcfg-rh
  • NetworkManager-dispatcher-routing-rules
  • NetworkManager-initscripts-updown

Fedora 41以降ifcfgがサポートされなくなることは、Fedora 39リリース時点で広報されていました。
Fedora39の変更点 - NetworkManager-initscripts-ifcfg-rhパッケージはFedora 41以降提供されない

本変更点は、NetworkManagerの設定ファイルを直接編集してnmcli connection load <file-name>で設定読み込みするような運用をしている場合に影響する可能性があります。
設定ファイルを直接いじらず、GUIやnmcli, nmtuiで運用している方には影響有りません。

設定ファイルの形式について詳細が気になる方は Fedora36の変更点 - /etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に をご覧ください。

network-scriptsの提供終了

RHEL6などで使われていたnetwork-scriptsというネットワーク設定/ステータス管理のツール群がFedora 41以降で提供されなくなります。
network-scriptsは既にアクティブな開発が停止している状況です。

「今後はNetworkManagerなど別のツールでネットワーク設定を管理していきましょう」ということだと思います。
Fedora 41以降の実機で確認すると、dnf list *network-scripts*でRPMパッケージを検索しても何もヒットしませんでした。

Kubernetestの複数バージョンがRPMリポジトリで提供されるようになった

Fedora 40までは、kubernetesパッケージの指し示すKubernetesのバージョンはFedoraのバージョンと1:1対応していました。
例えば、Fedora 40のRPMで提供されるKubernetesのバージョンは1.29に固定されていました。
Kubernetes 1.31が最新バージョンだったとしても、Fedora 40の公式リポジトリからインストールできるのはKubernetes 1.29のみです。
RPMS - kubernetes

一方で、Kubernetesは4ヶ月ごとにリリースされ、各リリースは1年間サポートされるというリリースサイクルです。
つまり、Kubernetesは常に3つのバージョンが同時に提供されています。

したがって、Fedora 40までは以下のような課題がありました。

  • 最新版のKubernetesをインストールできるとは限らない。ある時点で最新のKubernetesを使うために、半年に一度のFedoraリリースを待たなければならない。しかしFedoraがリリースされる頃には更に新しいKubernetesがリリースされているのでは...
  • Kubernetesのアップグレード時、前後でマイナーリリースバージョンが連続したアップグレードパスしかサポートされない (Kubernetes Documentationより)。Fedoraを使い続けているとどこかでKubernetesのバージョンが不連続になり、アップグレードできなくなる懸念があった

Fedora41以降はサポートされているKubernetesバージョン全てについてRPMを配布するようになりました。
それに伴い、パッケージ名も若干変わりました。
詳しくは以下の実機コマンド出力をご覧ください。

(Fedora 40)

dnf list kubernetes*
# Last metadata expiration check: 0:49:18 ago on Sun 03 Nov 2024 03:00:11 PM JST.
# Available Packages
# kubernetes.x86_64                         1.29.9-2.fc40                  updates
# kubernetes-client.x86_64                  1.29.9-2.fc40                  updates
# kubernetes-kubeadm.x86_64                 1.29.9-2.fc40                  updates
# kubernetes-systemd.x86_64                 1.29.9-2.fc40                  updates

(Fedora 41)

dnf list kubernetes*
# Updating and loading repositories:
#   Repositories loaded.
# Available packages
# kubernetes.x86_64             1.29.9-1.fc41  fedora
# kubernetes-client.x86_64      1.29.9-1.fc41  fedora
# kubernetes-kubeadm.x86_64     1.29.9-1.fc41  fedora
# kubernetes-systemd.x86_64     1.29.9-1.fc41  fedora
# kubernetes1.29.x86_64         1.29.10-2.fc41 updates
# kubernetes1.29-client.x86_64  1.29.10-2.fc41 updates
# kubernetes1.29-kubeadm.x86_64 1.29.10-2.fc41 updates
# kubernetes1.29-systemd.x86_64 1.29.10-2.fc41 updates
# kubernetes1.30.x86_64         1.30.6-1.fc41  updates
# kubernetes1.30-client.x86_64  1.30.6-1.fc41  updates
# kubernetes1.30-kubeadm.x86_64 1.30.6-1.fc41  updates
# kubernetes1.30-systemd.x86_64 1.30.6-1.fc41  updates
# kubernetes1.31.x86_64         1.31.2-1.fc41  updates
# kubernetes1.31-client.x86_64  1.31.2-1.fc41  updates
# kubernetes1.31-kubeadm.x86_64 1.31.2-1.fc41  updates
# kubernetes1.31-systemd.x86_64 1.31.2-1.fc41  updates

今後はバージョン番号付きのkubernetesパッケージを明確に指定してインストールすることが推奨されています。
そうすることでKubernetesのバージョンアップ作業もシンプルになります。 Fedora Quick Docs - Versioned rpm update recommendations

例えば、現時点でkubernetes1.30をインストール済みだったとします。
1.30系の中でパッチを更新する場合は、単純にsudo dnf upgradeを実行します。
1.30から1.31にバージョンアップしたい場合は、以下のコマンドを実行します。

# Remove and replace with kubernetes 1.30 and 1.31 as an example
sudo dnf remove kubernetes1.30 kubernetes1.30-kubeadm kubernetes1.30-client
sudo dnf install kubernetes1.31 kubernetes1.31-kubeadm kubernetes1.31-client

fedora-repoqueryコマンド

fedora-repoqueryパッケージがリリースされました。
他のディストリビューションのパッケージを検索するのに使えます。
(後述の実例を見たほうがイメージがつきやすいと思います)

fedora-repoqueryを使うには、以下のコマンドでインストールする必要があります。

sudo dnf install fedora-repoquery

では実際に使ってみます。

CentOS Stream 9で提供されているOpenSSHクライアントのバージョンを調べます。
c9がCentOS Stream 9を表します。

fedora-repoquery c9 openssh-clients
# openssh-clients-8.7p1-38.el9.x86_64 (c9s-BaseOS)
# openssh-clients-8.7p1-41.el9.x86_64 (c9s-BaseOS)
# openssh-clients-8.7p1-42.el9.x86_64 (c9s-BaseOS)
# openssh-clients-8.7p1-43.el9.x86_64 (c9s-BaseOS)
# openssh-clients-8.7p1-44.el9.x86_64 (c9s-BaseOS)

ディストリビューション名を省略すると、今のディストリビューションになります。

fedora-repoquery openssh-clients
# openssh-clients-9.8p1-3.fc41.1.x86_64 (fedora)
# openssh-clients-9.8p1-3.fc41.2.x86_64 (updates)

ディストリビューションやパッケージを同時に指定することも可能です。
以下の例では、CentOS Stream 9とEPEL 9 NEXTの両方を検索しています。
(補足: EPEL9はRHEL9用、EPEL9 NEXTはCentOS Steam9用のリポジトリです)

fedora-repoquery epel9-next c9 nodejs nodejs-devel
# nodejs-devel-16.18.1-5.el9.next.x86_64 (epel9-next)
# nodejs-16.20.2-3.el9.x86_64 (c9s-AppStream)
# nodejs-16.20.2-8.el9.x86_64 (c9s-AppStream)

ディストリビューション名として指定できるのは以下のキーワードです。
現時点でFedora, CentOS Stream, EPEL, EPEL NEXT, ELNに対応しています。
そのうちCoprにも対応するかもとのことです。

fedora-repoquery -l
# epel8 current
# epel9 current
# epel9-next current
# f39 current
# f40 current
# f41 current
# eln pending
# epel10 pending
# f41 pending
# rawhide pending
# f42 pending

以上、実際にLinuxをインストールしたりググったりすることなく他ディストリビューションのパッケージ構成を手軽に検索できるツール、fedora-repoqueryの紹介でした。

(参考) fedora-repoquery -lの細かい話

上記fedora-repoquery -lの出力について気になった部分があったので、軽く調べてみました。

確実な情報はないものの、currentやpendingはリポジトリのリリースステータスと思われます (Release.hs)。
pendingだからといってfedora-repoqueryの実装が仮であるという意味ではなく、あくまでリポジトリのステータスがpendingであると理解しています。
安心して使いましょう。

リリース済みのf42 (Fedora 42) のステータスがpendingである点が気になりましたが、こちらもおそらく正しいです。
fedora-repoqueryはBodhi ServerのREST APIから得られたjsonデータをパースしてリポジトリ名やステータス情報を取得しているようでした (Release.hs)。
おそらくAPIで取得している情報は、Bodhi Server上で動いているFedora Update System - Active Releasesなのではないかと思います。
2024/11/3時点でFedora 42が"Pending Releases"の配下にかかれていたので、fedora-repoquery -lはそれを忠実に反映したものと思われます。

iptablesからnftablesへの移行

Fedora 41以降、NetavarkとLibvirtのバックエンドがiptablesからnftablesに移行されました。
nftablesはiptablesの後継です。
netfilter.org - nftables

NetavarkとLibvirtとは何かについてそれぞれ補足します。

NetavarkはPodmanコンテナのネットワーク実装を担うプログラムのようです。

Libvirtは仮想化アプリケーションやハイパーバイザを操作するための抽象化レイヤーを提供するプログラムで、ライブラリやデーモンプロセスとして存在します (QEMU、KVM、libvirtの基礎知識まとめ - libvirt とは)。
LibvirtはKVM仮想マシンを管理するCLI (virshやvirt-install)、GUI (virt-manager, virt-viewer)、そして仮想化基盤であるKubeVirt (->OpenShift Virtualization), OpenStackなどに使われています (Applications using libvirt)。

iptablesからnftablesへの動きはFedora 32頃から段階的に進められてきました。
その背景について、後続の2セクションに詳しく書きました。
Fedora 41のアップデートから少し話が脱線するので、興味のある方のみお読みください。

(背景) ebtables, arptables, iptablesの話

元々以下のようなソフトウェアがありましたが、netfilterは全ての後継に当たるという位置づけです。
いずれのツールも同じような操作感でルール設定できるCLIになっています。

ソフトウェア名 動作タイミング 機能
ebtables Ethernet bridgeインターフェースにフレームが届いたとき フィルタ、NAT、brouteを設定できる (※)
arptables ARPを送受信したとき ARP送受信のフィルタを行う
iptables IPパケットを送受信するとき フィルタ (L4 Firewall)、NAT、その他の制御ができる

(※) フィルタとは、パケットの通過/ドロップを制御する機能のこと。NATとはアドレス変換 (ebtablesならMACアドレス変換)。brouteとは、bridgingせずそのままnetwork stackに処理を移行してL3以上の制御を行うこと

(※) broutingの参考リンク。brouterとは。brouterの実装例1。実装例2。実装例1より、brouterでL3スイッチを再現するには結構な量のルール記述が必要とわかる

(背景) 後継ツールであるnftablesへの段階的な移行

nftablesは、ebtables, arptables, iptablesの後継に当たるツールです。
nftというCLIでnftablesを操作できますが、文法が従来のebtables, arptables, iptablesとは全く異なります。

そこで、ebtables, arptables, iptablesと全く同じCLIを使いつつも、Linux Kernel側に実装されたAPIをnftables互換に寄せたプログラムが用意されました。
nftablesへの移行措置としてです。
nftablesに寄せたプログラムを含むRPMパッケージはiptables-nftという名前です。
iptables-nftにはebtables, arptables, iptablesの実行ファイルが全て含まれています。
併せて従来どおりの古いLinux Kernel APIに基づいて実装されたプログラムを含むRPMパッケージがebtables-legacy, arptables-legacy, iptables-legacyに名称変更されました。
この変更はFedora 32時点で行われました。
Fedora Wiki - Changes/iptables-nft-default

IPフィルタ機能について言うと、iptables-legacy, iptables-nft, nftという3つのCLIがあるということになります。
比較的新しいディストリビューションであればnftかiptables-nftを使っているはずです。
これら3つのツールの実装の違いについて詳しく説明したブログがあります。
読んでみると面白いので、ご参考までに掲載しておきます。
Red Hat Developer - iptables: The two variants and their relationship with nftables

併せて、firewalldのバックエンドもiptablesからnftablesに変更されました。
firewalldはL4ファイアウォール機能を提供するCLIフロントエンドです。
Fedora Wiki - Changes/firewalld default to nftables

そして今回、Fedora 42にてNatavarkとlibvirtのバックエンドもiptablesからnftablesへ移行されました。

RHELやFedoraに付属するツールの中で主だったものはiptablesからnftablesへ移行されてきた印象です。
もちろん、Dockerなど引き続きiptablesを使っているソフトウェアもまだまだ存在します。
Docker Docs - Packet filtering and firewalls

RedisをValkeyに置き換えた

「RedisのライセンスがRASLv2/SSPLに変わったことで、FedoraとしてRedisを提供することが厳しくなった」というのが経緯のようです。
ライセンスの詳しい話は理解しきれませんでしたので、詳しいところはリンク先を参照してください。

ValkeyはRedisのforkであり、Valkey 7.2.5時点ではRedisとの互換性が100%とのことです。

(参考) valkey-compat-redis

RedisからValkeyに移行するにあたり、valkey-compat-redisというRPMパッケージが用意されています。
中身は以下の通りシンプルです。

dnf repoquery -l valkey-compat-redis
# /usr/bin/redis-benchmark
# /usr/bin/redis-check-aof
# /usr/bin/redis-check-rdb
# /usr/bin/redis-cli
# /usr/bin/redis-sentinel
# /usr/bin/redis-server
# /usr/libexec/migrate_redis_to_valkey.sh

実行ファイルは全てvalkeyへのシンボリックリンクです。

ls -l usr/bin
# total 0
# lrwxrwxrwx. 1 root root 16 Oct  7 09:00 redis-benchmark -> valkey-benchmark
# lrwxrwxrwx. 1 root root 16 Oct  7 09:00 redis-check-aof -> valkey-check-aof
# lrwxrwxrwx. 1 root root 16 Oct  7 09:00 redis-check-rdb -> valkey-check-rdb
# lrwxrwxrwx. 1 root root 10 Oct  7 09:00 redis-cli -> valkey-cli
# lrwxrwxrwx. 1 root root 15 Oct  7 09:00 redis-sentinel -> valkey-sentinel
# lrwxrwxrwx. 1 root root 13 Oct  7 09:00 redis-server -> valkey-server

/usr/libexec/migrate_redis_to_valkey.shは、RedisからValkeyへの移行ツールです。
元々Redisで運用して設定ファイル等をカスタマイズしているときに、このスクリプトを実行すると移行できるようです (もちろんスクリプトの過信は禁物です。ダブルチェックしましょう)。
中身は既存のRedis設定ファイルやライブラリをValkeyのディレクトリに移動するmvや、redisをvalkeyに置換するsedコマンドが主でした。

Python 3.13

Fedora 40ではPython 3.12系でしたが、Fedora 41ではPython 3.13系になります。
Fedoraが最新バージョンのPythonに追従するのはいつもどおりの動きです。
他のプログラミング言語も同様に最新化されているはずです。

Pythonバージョンアップ時、毎回ユーザー権限でインストールしたPythonパッケージ (venvを含む) の移行が必要になります。
移行手順の差分が上述のFedora 41 Release Notesのリンクに書いてあるので、参考にすると良いと思います。

Python2系のサポート終了

Python公式ではPython2系がEnd of Lifeになって久しいですが、いよいよFedoraでも互換性のために残っていたPython2.7のRPMパッケージ提供を終了しました。
RHELやCentOS Streamでも既にRPMの提供が終了しています。

Bugs

f41タグ付きのCommon Issuesを確認しましたが、特に気になるものはありませんでした。

...が、手元の環境で別のバグを踏んだので紹介しておきます。

Cockpit MachinesからVMの表示・操作ができない

Fedora 41においてCockpitからVM操作ができない不具合が発生しています。
原因はSELinuxによる拒否です。
今後バグが対処され、selinux-policyパッケージが更新されれば解消される見込みです。
GitHub - cockpit-project/cockpit-machines - issue#1818
Bugzilla - 2316474 - SELinux is preventing pool-libvirt-db from 'connectto' accesses on the unix_stream_socket /run/libvirt/libvirt-sock.

バグを踏んでいる間はvirshコマンドやvirt-managerで代替することで何とか乗り切りましょう。
これらのツールは正しく動作することを確認できています。

#Linux #Fedora

stopendy 読者になる

広告を非表示にする
コメントを書く