えんでぃの技術ブログ

えんでぃの技術ブログ

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

Fedora40の変更点

Linux

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

公式情報の見方

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

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

fedora_change_sets

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

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

Release Notes & Changes

dnf実行時、filelistsを必要なときのみダウンロードするようになった

dnfでリポジトリを参照する際、操作内容によってメタデータをダウンロードします。
このメタデータの中にfilelistsと呼ばれるものがあります。

filelistsとは、そのリポジトリ内に含まれているrpmパッケージと、パッケージに含まれるファイル名すべてをxml形式で記録したファイルのことです。
見た目のサンプルとして、以下にzipパッケージの部分を抜粋します。

<package pkgid="feafa5144f815ab92fca16446ec7eea763e116a27e3c5716f7308a314e8138ba" name="zip" arch="x86_64">
  <version epoch="0" ver="3.0" rel="40.fc40"/>
  <file>/usr/bin/zip</file>
  <file>/usr/bin/zipcloak</file>
  <file>/usr/bin/zipnote</file>
  <file>/usr/bin/zipsplit</file>
  <file type="dir">/usr/lib/.build-id</file>
  <file type="dir">/usr/lib/.build-id/29</file>
  <file>/usr/lib/.build-id/29/bb2d05a3cf4baa7462a94a29ed39b97b44884b</file>
  <file type="dir">/usr/lib/.build-id/30</file>
  <file>/usr/lib/.build-id/30/ee0623bc9369b448a820bad6a65babf8e7e93f</file>
  <file type="dir">/usr/lib/.build-id/32</file>
  <file>/usr/lib/.build-id/32/57caf91e8de8514f0e3ba270d940e61f38b60d</file>
  <file type="dir">/usr/lib/.build-id/38</file>
  <file>/usr/lib/.build-id/38/7b7e0ad52e0c77ac310531fdc6f558841fccaa</file>
  <file type="dir">/usr/share/doc/zip</file>
  <file>/usr/share/doc/zip/CHANGES</file>
  <file>/usr/share/doc/zip/README</file>
  <file>/usr/share/doc/zip/README.CR</file>
  <file>/usr/share/doc/zip/TODO</file>
  <file>/usr/share/doc/zip/WHATSNEW</file>
  <file>/usr/share/doc/zip/WHERE</file>
  <file>/usr/share/doc/zip/algorith.txt</file>
  <file type="dir">/usr/share/licenses/zip</file>
  <file>/usr/share/licenses/zip/LICENSE</file>
  <file>/usr/share/man/man1/zip.1.gz</file>
  <file>/usr/share/man/man1/zipcloak.1.gz</file>
  <file>/usr/share/man/man1/zipnote.1.gz</file>
  <file>/usr/share/man/man1/zipsplit.1.gz</file>
</package>

このfilelistsですが、多くのdnf操作において必要とされません。
従来のdnfでは、dnf list <パッケージ名>やdnf repoquery <パッケージ名>のようにrpmに含まれるファイル名を必要としない操作においてもfilelistsをダウンロードしていました。

Fedora 40以降 (dnf 4.19.0以降) では、必要な場合を除いてデフォルトでfilelistsをダウンロードしないようになりました。
この変更により余分なメタデータのダウンロードが抑止され、キャッシュが効いていないときのdnf実行速度が大幅に向上しました。

(検証) メタデータダウンロードにかかる時間の比較

試しに私の環境のFedora 40 VMで実行速度とダウンロードサイズを比較してみました。

まず、従来どおりのfilelistsをダウンロードしたときの結果を示します。
事前にsudo dnf clean metadataでメタデータのキャッシュをクリアした上で試験しました。
メタデータのダウンロードサイズが合計87 MB、コマンド実行時間は約41秒です。
このデータは、filelistsをダウンロードするようわざわざ設定変更したFedora 40で取得したものです。

# time sudo dnf repoquery rpm
Fedora 40 - x86_64                             5.4 MB/s |  75 MB     00:14    
Fedora 40 openh264 (From Cisco) - x86_64       2.3 kB/s | 2.6 kB     00:01    
Fedora 40 - x86_64 - Updates                   8.6 MB/s |  12 MB     00:01    
rpm-0:4.19.1.1-1.fc40.x86_64

real    0m41.338s
user    0m27.085s
sys 0m1.616s

filelistsをダウンロードしないときの結果を示します。
一度sudo dnf clean metadataでメタデータのキャッシュをクリアし、filelistsをダウンロードしない設定に切り替えてから同じコマンドを実行しました。
ダウンロードしたファイルサイズは23.4 MB、実行時間は10.5秒まで短縮されました。

# time sudo dnf repoquery rpm
Fedora 40 - x86_64                             13 MB/s |  20 MB     00:01    
Fedora 40 openh264 (From Cisco) - x86_64       1.0 kB/s | 1.8 kB     00:01    
Fedora 40 - x86_64 - Updates                   4.2 MB/s | 3.4 MB     00:00    
Last metadata expiration check: 0:00:01 ago on Tue 30 Apr 2024 04:39:06 PM JST.
rpm-0:4.19.1.1-1.fc40.x86_64

real    0m10.500s
user    0m7.043s
sys 0m0.432s

(検証) filelistsはどこに存在するのか？

/var/cache/dnf/リポジトリ名-英数字/repodata/英数字-filelists.xml.拡張子にありました。

それぞれ圧縮されているので、中身を見るにはunzckやgunzipといったコマンドで解凍してから開く必要があります。
unzckコマンドは、Fedoraであればsudo dnf install zchunkでインストールできます。

ファイルの中身については先ほどのセクションですでに示したので割愛します。

# find /var/cache/dnf/ -name '*filelists*' | xargs du -h
56M /var/cache/dnf/fedora-6c3a9e5977a00788/repodata/a07f2d719480923d5a2af772eed004eef5c1c6c1032258b740c9515fba82c173-filelists.xml.zck
8.2M   /var/cache/dnf/updates-02a32a5ce99e20ab/repodata/42fba8b75ea15274d85d9c5ea56242b341628e2c04bfad2979d390c535f80a57-filelists.xml.zck
8.0K   /var/cache/dnf/fedora-cisco-openh264-3e5cc8d7297aea85/repodata/c339739d50e2ae7ff271d6987aa9d95f37cec4da942afa0dc96bbe977e5cd333-filelists.xml.gz

(検証) Fedora 39とFedora 40の挙動を比較してみる

以下の手順を様々なパターンで試しつつ、挙動を比較してみました。

  1. sudo dnf clean metadataを実行し、メタデータのキャッシュを削除する
  2. dnfコマンド (A) を実行する
  3. find /var/cache/dnf/ -name '*filelists*'を実行し、filelistsが生成したかどうかを確認する (B)

結果は以下の通りです。
※/var/cache/dnf/配下にキャッシュ格納するのはrootユーザのみなので、本試験はすべてrootユーザで実施しました (一般ユーザは/var/tmp/dnf-ユーザ名-乱数/配下にキャッシュ格納します)

試験ID Fedoraバージョン dnfコマンド (A) filelistsは生成したか (B)
1 Fedora 39 sudo dnf repoquery rpm 生成した
2 Fedora 39 sudo dnf repoquery -l rpm 生成した
3 Fedora 40 sudo dnf repoquery rpm 生成しなかった
4 Fedora 40 sudo dnf repoquery -l rpm 生成した

結果 (B) から、全てこれまでに説明した仕様通りになっていることが読み取れました。

最下行の試験4について補足すると、dnf repoquery -lはRPMパッケージ内に含まれるファイルを列挙するコマンドです。
このコマンドはfilelists相当の情報を要求するため、filelistsが生成することは想定どおりです。
(今回のケースでは全パッケージの情報を取得する必要はないのですが、そこはdnfの仕様がそうなっているのだと理解しました)

(補足) filelistsを常にダウンロードする方法

従来どおりfilelistsを常にダウンロードしたい場合は、/etc/dnf/dnf.confにおいて、以下の行を[main]セクションの配下に追記します。

optional_metadata_types=filelists

wgetがwget2に置き換わった

Fedora 40ではwgetがwget2に置き換えられました。
wget2は従来のwgetとは異なるライブラリを利用していて、より活発に開発が行われているとのことです。

Fedora 40の公式リポジトリでは、従来バージョンのwgetのRPMファイルは提供されなくなりました。

wgetとwget2の機能差分

以下のページにwgetとwget2の機能差分がまとめられています。
GitLab - gnuwget/wget2 - Wiki - #Different behavior of Wget2

wget2ではFTP、WARC (Web Archive)関連のオプションが今のところサポートされないようです。
代わりにhttp2, hsts, 統計値の表示など多くの機能が追加されています。

パッケージ構成の違い

従来のwgetパッケージが以下2つのパッケージに置き換えられました。

パッケージ名 内容
wget2 wget2実行ファイルを含むwget2本体
wget2-wget wgetをwget2に差し替えるファイル群。
/usr/bin/wget -> wget2というシンボリックリンクなど

これにより、wgetコマンドを実行するとwget2コマンドが実行されます。
また、man wgetを実行するとman wget2が参照されます。

NetworkManagerにて、IPv4のアドレス重複検知がデフォルト有効に

Fedora 39以前ではIPv4のアドレス重複検知機能がデフォルト無効でしたが、Fedora 40以降ではデフォルト有効になります。

内部的には、ipv4.dad-timeoutのデフォルト値が変更されました。
とはいっても、nmcli connection show <connection-name>で表示されるipv4.dad-timeoutの値はFedora 39でもFedora 40でも-1のままです。
-1とは、「デフォルト値に従う」ことを意味します。
nmcliの出力やNetworkManager.confなどの設定ファイルには更新がありませんが、デフォルトの挙動が変わったのが今回の差分です。

ちなみにipv4.dad-timeoutの値が0の場合は無効化、1〜30000の場合はミリ秒単位でDAD (Duplicate Address Detection) のために実行されるARP Probeのタイムアウト値が指定されます。
man nm-settings-nmcliに記載の通り、実際には指定した値の等倍〜半分の間の値が乱数で決定されてタイムアウト値として使用されるとのことです。

(補足) DADとは、Duplicate Address Detectionの略です。インターフェースがupしたときにARP Probeと呼ばれる「自分のIPアドレスをセットしたARP Request」をブロードキャストで送信し、万が一応答があった場合にIPアドレス重複として検知する仕組みです。次セクションの検証結果を先にお伝えすると、Fedora 40においてIPアドレス重複を検知した場合、静的なIPアドレスであればインターフェースをupせず、動的なIPアドレスであれば別の利用可能なIPアドレスを代わりにアサインするという動きになりました。

(検証) 実際にIPv4アドレス重複させてみる

以下3台のVMを予め用意しておきます。

Fedoraバージョン ホスト名 IPv4アドレス割当方式 IPv4アドレス
Fedora 40 fedora40-dhcp dhcp 192.168.122.158/24
Fedora 40 fedora40-manual manual 未設定
Fedora 39 fedora39-manual manual 未設定

fedora40-manualに対して以下のコマンドを実行し、fedora40-dhcpとIPアドレスを重複させてみます。
すると、30秒前後経過した後にエラーメッセージが出てConnectionの有効化に失敗します。

fedora40-manual# sudo nmcli connection add ifname enp1s0 con-name test type ethernet ipv4.method manual ipv4.addresses 192.168.122.158/24

# Connectionの有効化に失敗する
fedora40-manual# time sudo nmcli connection up test
# Error: Connection activation failed: IP configuration could not be reserved (no available address, timeout, etc.)
# Hint: use 'journalctl -xe NM_CONNECTION=0e08924a-c79c-4672-b148-31d0d492aec5 + NM_DEVICE=enp1s0' to get more details.
# real 0m32.095s
# user 0m0.032s
# sys  0m0.019s

# 元々のConnectionのまま
fedora40-manual# nmcli connection show
# NAME    UUID                                  TYPE      DEVICE 
# enp1s0  f4d9f489-6247-383a-9fb2-0b7c84e762ec  ethernet  enp1s0 
# lo      5077f790-ccff-4a25-9f6b-4cfdfad2df57  loopback  lo     
# test    0e08924a-c79c-4672-b148-31d0d492aec5  ethernet  --   

# ログを抜粋。IPアドレス重複のエラーが出ていた
fedora40-static:~# journalctl --no-pager -eu NetworkManager.service
# May 01 01:31:12 fedora40-static NetworkManager[897]: <warn>  [1714494672.4948] device (enp1s0): IP address 192.168.122.158 cannot be configured because it is already in use in the network by host 52:54:00:4B:B9:2A

fedora39-manualでも同様の操作を行い、IPv4アドレスを重複させてみます。
今度は一瞬でIPアドレス設定が完了し、容赦なくIPアドレス重複が発生します。

fedora39-manual# sudo nmcli connection add ifname enp1s0 con-name test type ethernet ipv4.method manual ipv4.addresses 192.168.122.158/24

# Connectionの有効化に成功する
fedora39-manual# time sudo nmcli connection up test
# Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)

# real 0m0.112s
# user 0m0.010s
# sys  0m0.011s

更にIPアドレス重複が発生させた状態で、fedora40-dhcpのインターフェースを一度downさせ、その後upさせてみます。
すると元の192.168.122.158/24ではなく、別の192.168.122.159/24が動的にアサインされます。

fedora40-dhcp# sudo nmcli connection down enp1s0
fedora40-dhcp# time sudo nmcli connection up enp1s0
# Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)

# real 0m13.406s
# user 0m0.015s
# sys  0m0.016s

今回の検証結果をまとめると、以下のようになりました。

  • Fedora 40以降、IPv4アドレス重複検知機能がデフォルトで有効化された (Fedora 39以前ではデフォルト無効だった)
  • 静的なIPアドレス設定で重複を検知した場合、30秒程度でConnectionの有効化に失敗した
  • DHCP構成でlease期限内のIPアドレスが重複していることを検知した場合、13秒程度で次の空きIPアドレスを利用した
    • (補足) RFC5227ではDHCP ClientがDHCP DECLINEを送付することまで規定されているものの、IPアドレス設定のエラーを返すか次の空きIPアドレスを使うかの判断は実装に委ねられていた

Python 3.7のRPM提供終了

python3.7パッケージがFedora 40のリポジトリで配布されなくなりました。
dnf provides python3.7と検索してもRPMが見つからなくなりました。

なお、Python 3.7は2023/6/27にEnd of lifeになりました。
(Python Developer's Guide - Status of Python versions)

背景には以下の事情があったとのことです。

  • End of lifeになってからもDebian 10 "Buster" LTSのテストのためにPython3.7を残しておいた
  • Fedora 40がリリースされる頃にはDebian 10もEnd of lifeになるため残しておく理由がなくなった

RHEL 8のサポートが継続していることを理由として、Python 3.6についてはFedora 40でも引き続き提供されるとのことでした。

Bugs

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

Fedora39の変更点

Linux

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

私目線では、今回のFedora39リリースにはあまり大きな変更がありませんでした。

公式情報の見方

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

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

fedora_change_sets

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

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

Release Notes & Changes

Bashプロンプトに色がついた

Fedora 38以前ではBashプロンプトには色がついていませんでしたが、Fedora 39以降では色がつくようになりました。
また、直前のコマンドのExit Statusが0以外の場合にプロンプト文字列として表示されるようになりました。

↓従来のプロンプト

monochrome-bash-prompt

↓Fedora 39以降のプロンプト

colored-bash-prompt

なお、この色付けはログインシェルに対してしか適用されません。

具体的には、SSHでログインした場合には適用されません。
SSHでログインしたあと、更に手動でbashコマンドを実行すると適用されます。

login_to_colorize_bash

PROMPT_COLOR変数にカラーコードを入れることで、任意の色に変更できる作りになっています。
カラーコードの書き方はbash:tip_colors_and_formattingが参考になります。
以下の例では35がPurple、96がLight Syan、33がYellow、1がBold (太字) という意味になります。

prompt_color_to_customize

SSHログイン時も反映したい場合は、以下のスクリプトを~/.bashrcに追記します。
sourceコマンドの後にPROMPT_COLORを変更してもしっかり反映される作りになっています。

source /etc/profile.d/bash-color-prompt.sh
# PROMPT_COLOR=33

Bashプロンプト色付けの詳細

今回の変更は、Fedora39以降に初期インストールされているbash-color-promptというRPMパッケージによって導入されました。

rpm -ql bash-color-prompt、またはdnf repoquery -l bash-color-promptによってインストールされたファイル群を確認すると、/etc/profile.d/bash-color-prompt.shというシェルスクリプトが追加されていることがわかります。
シェルスクリプトの中身を見てみましょう。

if [ "$PS1" = "[\u@\h \W]\\$ " -a "${TERM: -5}" = "color" -o -n "${prompt_color_force}" ]; then
    PS1='\[\e[${PROMPT_COLOR:-32}m\]\u@\h\[\e[0m\]:\[\e[${PROMPT_COLOR:-32}m\]\w\[\e[0;31m\]${?#0}\[\e[0m\]\$ '
fi

ちょっと読むのが辛いかもしれませんが、最初のif文は以下の意味です。

  • PS1変数が初期値かつ、TERM変数がcolorで終わる場合 (手元の環境ではTERM=xterm-256colorでした)
  • または、prompt_color_force変数が空ではない場合

そして条件にマッチしたとき、PS1を書き換えています。
PS1はBashの中で特殊な意味を持つ変数であり、この変数を書き換えることでプロンプト文字列を変更できます。
(参考) Bash Reference Manual - Controlling the Prompt

以上より、Bashにログインしたときに特定の条件を満たしていればプロンプトがカスタマイズされることがわかりました。

上記スクリプトは/etc/profile.d/配下に書かれているので、「bashログイン時」のみに実行されます。
そのためSSHログイン時も含めてbash起動時もプロンプト文字列を変更したい場合には、~/.bashrcをカスタマイズする必要がありました。

KickstartにDNS関連のオプションが追加された

Kickstartで以下のオプションを追加で使えるようになりました。
いずれもネットワークインターフェースに紐づけて設定するDNS関連のオプションです。

オプション名 意味
--ipv4-dns-search
  • NetworkManagerのipv4.dns-searchに相当
  • 通信の宛先にDNSショートネームを指定した場合に
    自動補完するドメイン名を指定する
  • IPv4に対してのみ有効
--ipv6-dns-search
  • 同上
  • ただしIPv6に対してのみ有効
--ipv4-ignore-auto-dns
  • DHCPによるDNSサーバ自動設定を無効化する
  • IPv4に対してのみ有効
--ipv6-ignore-auto-dns
  • 同上
  • ただしIPv6に対してのみ有効

EFIファイルシステムの最小サイズが200 MiBから500 MiBに拡張

マザーボードのファームウェアにBIOSではなくUEFIを使っている方に該当します。
ESP (EFI System Partition) という先頭に作られるパーティションのサイズが最小200 MiBから500 MiBに引き上げられました。
ファームウェア更新時に必要な空き容量が近い将来引き上げられることが背景にあります。

ESPの最大サイズは従来の600 MiBのまま変更ありません。
また、BIOSをお使いの方には影響ありません。

NetworkManager-initscripts-ifcfg-rhパッケージはFedora 41以降提供されない

この変更はNetworkManagerをGUI、nmcli、nmtuiなどで操作している方には影響ありません。
RHEL6時代まで続いたnetwork-scripts形式の設定ファイルを編集して運用している方に影響があります。

NetworkManager-initscripts-ifcfg-rhパッケージについて、詳細はFedora36の変更点 - /etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効にを参照してください。

Python 3.12

Fedora 38ではPython 3.11系でしたが、Fedora 39系ではPython 3.12系が提供されるようになります。

Fedoraはリリースのたびに最新のPythonバージョンに追従することが基本ポリシーのようです。
(おそらく他の言語も同様ですが、Python以外はチェックしていません)

Bugs

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

まとめ

興味を持ったトピック限定ですが、Fedora39の更新点をまとめました。

Fedora38の変更点

Linux

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora38のリリースノートを読んで、個人的に気になった項目をまとめ...ようと思いましたが、今回は私目線で気になる更新点は1つもありませんでした。

リリースノートの読み方や不具合情報の探し方については、以下の過去記事を参照してください。
Fedora37の変更点 - #公式情報の見方

以上。

Fedora37の変更点

Linux

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

私目線では、今回のFedora37リリースにはあまり大きな変更がありませんでした。

公式情報の見方

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

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

fedora_change_sets

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

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

Release Notes & Changes

Python 3.11

Fedora36時点ではPython3.10が同梱されていましたが、Fedora37以降はPython3.11が同梱されます。

Bugs

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

強いて言うなら、GNOME Desktopをお使いの方はざっとタイトルをチェックしてみると良いと思います。

その他

Kickstartのオプション

LinuxなどのOSインストールを自動化するKickstart処理のオプションとして、rootユーザーのパスワードを指定するrootpwというコマンドがあります。
このrootpwコマンドに、Fedora37から--allow-sshオプションが追加されました。

このオプションを指定すると、rootユーザーに対してSSHによるパスワードログインが許可されます。

なお、--allow-sshオプションはRHEL9でも利用可能です。
RHEL9 - Performing an advanced RHEL 9 installation - #rootpw

本件はFedora 37のRelease Notesには掲載されていませんでしたが、--allow-ssh付きのKickstartファイルでFedora36をインストールしようとしたときにエラーになったことでたまたま気づきました。

まとめ

興味を持ったトピック限定ですが、Fedora37の更新点をまとめました。

Fedora36の変更点

Linux

Fedoraの変更点シリーズ

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

Fedoraの変更点シリーズ

お伝えしたいこと

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

公式情報の見方

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

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

fedora_change_sets

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

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

Release Notes & Changes

remove-retired-packagesコマンドがインストール可能に

Fedora公式リポジトリでremove-retired-packagesというパッケージの配布が開始されました。

remove-retired-packagesコマンドを使うと、その名の通りretired packagesを自動的に検出してアンインストールを提案してくれます。

retired packagesとは、Fedora公式リポジトリで配布されなくなったパッケージのことです。
retired packagesになる主な理由は、アップストリームの更新が停止したことが挙げられます。

デフォルトでは1世代前のFedoraバージョンからretired packagesを検出して、対象のパッケージに対してdnf removeを実行します。
remove-retired-packages 34のように引数を指定することで、検索範囲を広げてくれます。

更新が停止したパッケージを残しておくとセキュリティリスクがありますので、Fedoraをバージョンアップするたびにこのコマンドを実行することが推奨されます。

過去記事のFedoraのOSバージョンアップ手順にremove-retired-packagesの使い方を追記しましたので、詳細はこちらをご覧ください。

/etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に

Fedora36以降、NetworkManagerはデフォルトで/etc/sysconfig/network-scripts/ifcfg-*ファイルを一切使わなくなります。
それどころか、/etc/sysconfig/network-scripts/フォルダ自体存在しなくなります。
追加のRPMパッケージをインストールすれば従来の構成に戻すことは可能ですが、ifcfg-*は今後なくなっていく流れですので、それに逆行することは推奨しません。

Connectionの定義ファイルを直接見ることがない方にとっては、この変更点はほぼ影響ありません。
例えば、普段nmcliを使っている方に取ってはあまり気にならないと思います。
もしもifcfg-*ファイルを編集してnmcli reloadやsystemctl restart NetworkManager.serviceなどで設定を再読込する運用をしている方がいれば、今回の変更は重要なものになります。
少数派だと思いますが...。

では、詳細に移ります。
この先は興味のある方のみお読みください。

全体像を理解するために、今までのLinuxのネットワーク設定変更の主だった動きを追ってみます。
私の知識の偏りにより、RHELとFedoraが混在した時系列になっていますがご了承ください。

RHEL6の頃、ネットワーク設定変更といえば以下の流れが主流でした。

  • /etc/sysconfig/network-scripts/ifcfg-*ファイルを編集する
  • service network restartによって反映する

RHEL7以降は、NetworkManagerを常時有効化することが主流となりました。
NetworkManager利用した設定変更の方法は複数ありますが、nmcliコマンドによる変更が最も基本的だと思います。

NetworkManagerには、/etc/NetworkManager/NetworkManager.confという設定ファイルがあります。
この設定ファイルにはpluginsという設定項目があり、デフォルトではコメントアウトされています。

#plugins=keyfile,ifcfg-rh

nmcliなどで変更したconnection設定はOS再起動後ももちろん残ります。
その裏では、NetworkManagerが設定内容をファイルに保存しています。

私はあまりやったことがないのですが、NetworkManagerを使っている環境においてもこの設定ファイルを書き換えて、nmcli connection reloadコマンドによって設定ファイルを再読込させることが可能です。
ファイルを書き換えるよりも、nmcli connection modifyコマンドを使うほうが一般的だと思いますが...。

さて、この「Connection設定が保存されたファイル」がどのような形式で、どういったファイルパスに保存されるかを指定するのが上述のplugins設定です。
plugins設定はNetworkManager.confで明示的に指定することが可能ですが、コメントアウトされている場合にはディストリビューション固有のデフォルト値を取ります。

pluginsの取りうる値は、man NetworkManager - #PLUGINSに書いてあります。

ここで紹介するpluginsは以下の2つのみです。

plugins 説明
keyfile
  • 最も基本形のフォーマット
  • NetworkManagerと必ず同梱される
  • INI形式
  • /etc/NetworkManager/system-connections/*に格納される
ifcfg-rh
  • RHEL系のレガシーなフォーマット
  • /etc/sysconfig/network-scripts/ifcfg-*に格納される

ここでFedoraバージョン依存の話が出てきます。

Fedoraのバージョンが上がるにつれて、pluginsのデフォルト値は以下のように変遷しました。1

バージョン pluginsのデフォルト値
Fedora32以前 ifcfg-rh,keyfile
Fedora33以降 keyfile,ifcfg-rh

ifcfg-rh,keyfileは、「基本的にifcfg-rhを優先するが、もしこのPluginが利用不可だった場合にはkeyfileを使う」という意味です。
keyfile,ifcfg-rhはその逆で、「keyfileを優先し、次にifcfg-rhを使う」という意味になります。

keyfile Pluginは、NetworkManagerのRPMファイルに必ず同梱されます。
一方で、ifcfg-rhについてはFedoraのバージョンによって以下のように構成が変わりました。
これがFedora36の差分です。

バージョン RPMパッケージ
Fedora35以下
  • NetworkManagerに同梱される
  • 初期状態でifcfg-rhプラグインを利用可能
Fedora36以降
  • NetworkManager RPMパッケージに同梱されない
  • 初期状態ではifcfg-rhプラグインを利用不可
  • NetworkManager-initscripts-ifcfg-rh
    RPMパッケージを別途インストールすれば使える

Fedora36以降は、ifcfg-rhプラグインがデフォルトでインストールされません。
また、/etc/sysconfig/network-scripts/ディレクトリもデフォルトで存在しません。

レガシーなifcfg-rhは今後なくなっていく流れですので、今後はkeyfileを使うことを前提に考えると良いと思います。

NetworkManager-initscripts-ifcfg-rh RPMパッケージを導入してifcfg-rhを使い続けるという選択肢もありますが、恐らくあまり良い選択ではありません。
このパッケージが今後提供されなくなる可能性が少なくないためです。

Bugs

Bugsの中から気になる情報を拾います。

Fedora36にアップデートした後SELinuxの不具合が出る

タイトルのとおりです。
投稿された事例では、dnf upgrade, flatpak update, setseboolなどのコマンドを実行した時にWarningが出たとのことです。

回避策は、Fedoraをバージョンアップする前にsudo dnf upgradeでパッケージを最新化しておくことです。
これはFedoraバージョンアップの公式手順にも記載されていることですので、マニュアル通りに作業していれば問題ありません。

Fedora36で事象が発生してしまったときのワークアラウンドとしては、以下が紹介されています。

  1. SELinux関連パッケージを再インストールする
  2. 1で直らなかった場合は以下を実施
    1. SELinuxの関連モジュールを停止する
    2. SELinux関連パッケージを再インストールする
    3. SELinuxのrelabelを行う

サイト上で紹介されているコマンドは一例です。
環境に応じて実行するコマンドを変更する必要があると思います。

ちなみに、私がもし事象を踏んだときは以下の手順で対処すると思います。
私は事象を踏んでおらず、未検証の手順なのでご参考までに...。

まず、事象を踏んだときのコマンドを覚えておきます (sudo dnf upgradeなど)。

続いて、SELinux関連パッケージを再インストールします。
この時、再インストールすべきパッケージは以下のコマンドで洗い出します (※)。
(※) SELinuxのコアなパッケージはselinux-policyとselinux-policy-targetedの2つです。そして、製品に対応したSELinuxの追加ルール (Security Policy) をインストールするパッケージは、製品名-selinuxというパッケージ名であることが多いです。したがって、以下のコマンドで必要なパッケージは一通り洗い出せます

dnf list installed *selinux*

上記を実施後、事象が継続しているかを確認します (例えば、sudo dnf upgradeを実行し、Warningが発生するかを確認します)。

事象が継続している場合、以下の手順を実施します。

個人的には、sudo fixfiles onbootに-Fを指定する必要はないかなと思います。
-Fを指定しても害はありませんが、通常の環境 (targeted policy) では指定してもしなくても差はありません。

まとめ

興味を持ったトピック限定ですが、Fedora36の更新点をまとめました。

  1. Fedora wiki - Changes/NetworkManager keyfile instead of ifcfg rh↩

FedoraにSlackをインストールする方法 (Snap利用)

Linux

お伝えしたいこと

Snapによって、FedoraにSlackをインストールする手順を紹介します。

FedoraでSlackをインストールする場合、現状Snapを使うのが最も無難な方法だと思います。
その理由については、#(参考) Snapを使う理由に記載しましたので、興味のある方はご確認ください。

Snapとは

SnapはLinuxにソフトウェアをインストールするパッケージの1種です。
以下の特徴を持ちます。1

Snapdのインストール

snapコマンドはsnapdデーモンと共に動作します。
Fedora上でsnapコマンドを使用するために、snapdをインストールします。

sudo dnf install snapd

snap versionでsnapやsnapdのバージョンが表示されれば、正しくインストールできています。

snap version
# snap    2.55.3-2.fc35
# snapd   2.55.3-2.fc35
# series  16
# fedora  35
# kernel  5.16.12-200.fc35.x86_64

インストール後、一旦ログインし直します。
再ログイン後、PATHの末尾に/var/lib/snapd/snap/binが追加されます。
これにより、Snapでインストールした実行ファイルにPATHが通るようになります。

echo $PATH
/home/stopendy/.local/bin:/home/stopendy/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/var/lib/snapd/snap/bin

なお、PATHの追加は、/etc/profile.d/snapd.shにて行われていました。

Slackのインストール

Snapでパッケージをインストールする際は、以下の流れで進めます。

  1. パッケージを探す
  2. Confinementを確認する
  3. インストールする

パッケージを探す

snap findコマンドでパッケージを部分一致検索できます。

snap find slack
# Name   Version  Publisher  Notes  Summary
# slack  4.25.1   slack✓     -      Team communication for the 21st century.
# (以下略)

Publisherがslack✓と記載されている通り、チェックマークがついています。
これはパッケージメンテナがSnapの運営元によって公式であると確認済みであることを示しています (※)。
(※) snap find --helpより

パッケージは、snapcraftのWEBサイト上でも検索できます。
https://snapcraft.io/slack

Confinementを確認する

オンラインリポジトリ上のSnapのConfinementを確認するには、snap info --verboseコマンドを使います。

snap info --verbose slack
#   confinement:       strict
# (一部のみ抜粋)

Confinementは、Snap上で動作するアプリケーションがシステムに対してどの程度アクセス権限を持つかを表します。
Confinementの値によってはインストール手順が若干変わってくるので、ここで確認しておく必要があります。

ConfinementはSnapパッケージがビルドされた時点で決まっています。
したがって、私達ユーザーが選ぶことはできません。

Confinementは3つの値を取りえます。
私達が使うパッケージは、通常strictかclassicのいずれかです。3, 4

  • strict
    • 最も一般的なconfinement
    • アプリケーションからシステムへのアクセスを適切に制限する
    • アクセス先によっては、ユーザー操作を求める (カメラなど)5
    • 許可されないアクセスは拒否する
  • classic
    • アプリケーションからシステムへのアクセスを無条件で許可する
    • classicのパッケージをインストールする前に#初期設定が必要
    • sudo snap install --classicでインストールする
  • devmode
    • 開発者向けのモード
    • 許可されないアクセスはログ出力するが、実際には許可される
    • アプリが必要とする権限の洗い出しに使えそう
    • sudo snap install --devmodeでインストールする

インストールする (strict confinementの場合)

以下のコマンドでSlackをインストールします。
Slackパッケージのconfinementはstrictなので、特にオプション指定は不要です。

sudo snap install slack

その他の基本コマンド

インストール済みのSnapパッケージを一覧表示します。

snap list
# Name   Version  Rev  Tracking       Publisher  Notes
# slack  4.25.1   61   latest/stable  slack✓     -
# (一部抜粋)

パッケージを更新するコマンドです。

sudo snap refresh

Snapパッケージを削除するコマンドも記載します。

デフォルトでは、snap restoreによって復元するためのデータを保管します。
この場合はsnap remove後もsnap listでパッケージが表示されます。
--purgeオプションを指定することで、復元用のデータを残さずに削除します。

# sudo snap remove --purge slack

(参考) Snapを使う理由

2022年3月1日以降、SlackはFedora公式リポジトリで配布されなくなりました。

slack.com - System requirements for using Slack

slack_system_requirements

SlackをFedora Linux上で動作させる公式の手段は主に2つです。

  1. RPMファイルを公式サイトからダウンロードしてインストールする
  2. Snap版のSlackをインストールする

1のRPMは、Slackのリポジトリ情報を含みません。
したがって、今後Slackをバージョンアップしたいときには都度RPMファイルをダウンロードしてインストールする必要が出てきます。
これではあまりに不便です。

そこで、2のSnap版が出てきます。
Snap版であればオンラインリポジトリにSlackが配布されているので、sudo snap refresh slackコマンド1つでSlackをバージョンアップできます。

Fedora上でSlackを使いたい場合には、Snapを使うのが正攻法だと思います。

管理が面倒になるので、DNF以外のパッケージマネージャーを使うことには多少なりとも抵抗を覚えるかもしれません。
しかし、FedoraからSlack公式のリポジトリを使うにはSnapしか現状なさそうなので、私は割り切りました。

(参考) classic confinementのパッケージインストール

classicの場合の手順についても触れておきます。
今回はVS Codeをモデルにします。

VS CodeはFedoraのリポジトリで提供されるので、わざわざSnapでインストールする必要はありません。
ここでVS Codeをインストールしているのは、あくまで例示のためです。

Confinementの確認

VS Codeのconfinementは、2022年5月現在classicです。

snap info code --verbose
# publisher: Visual Studio Code (vscode✓)
#   confinement: classic
# (一部抜粋)

初期設定

Classic confinementのパッケージをインストールするには、/snapにシンボリックリンクを作成しておく必要があります。6

sudo ln -s /var/lib/snapd/snap /snap

シンボリックリンクを作成せずにインストールしようとすると、以下のようなエラーが出ます。

sudo snap install --classic code
# error: cannot install "code": classic confinement requires snaps under /snap or symlink from /snap
#        to /var/lib/snapd/snap

インストール

インストールの際は--classicオプションを付与します。

sudo snap install code --classic

--classicオプションを付与しないと、以下のエラーが出ます。

sudo snap install code
# error: This revision of snap "code" was published using classic confinement and thus may perform
#   arbitrary system changes outside of the security sandbox that snaps are usually confined to,
#   which may put your system at risk.

#   If you understand and want to proceed repeat the command including --classic.

まとめ

Snapによって、FedoraにSlackを導入する手順を紹介しました。

Linux PC関連まとめ

endy-tech.hatenablog.jp

  1. snapclaft.io - About Snaps↩

  2. snapclaft.io - Installing snapd↩

  3. snapclaft.io - Snap confinement↩

  4. snapclaft.io - Snap install modes↩

  5. snapclaft.io - Supported interfaces → 表の “AUTO-CONNECT” 列を参照↩

  6. snapclaft.io - Installing snap on Fedora↩

GNS3で踏みがちなトラブルと回避方法

Network GNS3

お伝えしたいこと

GNS3は幾度もリリースされ、今ではかなり安定して動作します。

しかし、それでもGNS3を使っていると現実のネットワーク機器では考えられないようなトラブルに見舞われることがあります。
VMが起動しなかったり、ケーブル直結なのにARPが通らなかったり...。

本記事では、GNS3を使っている時に踏みがちなトラブルと回避方法を紹介します。

文字化け

GNS3において、日本語 (※2バイト文字) は全力で避けてください。
GNS3上のマシン名はもちろんのこと、GNS3のバックエンドで動作しているVirtualBoxやQEMU上のVM名やファイルパスも含めてです。
VMだけでなく、仮想ディスクやISOファイルのファイル名、ファイルパスも気をつけてください。

GNS3が発行する命令に日本語が混ざると、文字化けしてエラーになります。
結果として、仮想マシンの起動/停止/追加/削除が一切できなくなります。

参考情報として、GNS3が各種連携ソフトに命令を送るイメージを下表に示します。
以下のnameに日本語が混ざると不具合の原因になります。

仮想化エンジン コマンドイメージ
VMware Workstation Player vmrun [options...] name
VirtualBox VBoxManage [options...] name
Docker docker [options...] name
QEMU qemu-system-x86_64 [options...] name

GNS3 GUI上の操作は電源を切ってから

GNS3 GUI上の操作とは、以下のようなものを指します。

  • GNS3上のケーブル配線
  • GNS3のノードを右クリックしてConfigureからの設定変更

もちろん、コンソール接続や電源OFF操作などは問題ありません。

これらの操作を行うと、本来通るはずの通信が通らなくなることがあります。
結果として、ケーブルで直結されたLinuxからARPを出してもL2スイッチ上でMACアドレステーブルを学習しない...なんてホラーが起こりえます。
「VACL設定したっけ...？」と頭を悩ませるより先に、まずはGNS3観点で疑いましょう。

この事象から復旧するには、以下のいずれかの操作が必要です。

  • 操作箇所に隣接する全てのVMの電源OFF/ON
  • 操作箇所に隣接する全てのVMの削除/再作成
  • GNS3の再起動
  • ホストマシンのOS再起動

面倒ですが、ホストマシンのOS再起動が最も確実です。

仮想マシンをグループに所属させないこと

VirtualBoxは、仮想マシンを右クリックしてグループに追加できます。
...が、この機能を使ったときGNS3が正しく動作しないことがあります。
あまり仮想マシンをグループに追加しないほうが良いと思います。

具体例としては、以下の操作を行った時にGNS3 Projectを開けなくなりました。
結果として、GNS3 Projectを作り直すことになりました...。

  • VirtualBox VMをVirtualBox上でグループに追加する
  • GNS3上でUse as a linked base VMを有効化する
  • GNS3 Projectを保存して、GNS3を一旦終了する
  • 保存したGNS3 Projectを開き直す

セキュリティソフトに要注意

GNS3は内部的に様々な実行ファイルを実行し、またlocalhostに対してTCP/UDP通信を行います。

GNS3をWindowsで動かしているとき、Windowsファイアウォールがしばしばこのような通信をブロックします。
結果として、 GNS3上ではケーブルが直結しているのに何故か通信が通らない といったことになります。
原因は、GNS3上の通信に利用されているUDP Tunnel通信をブロックしているためです。

Windowsファイアウォールであれば、設定にもよりますが通信をブロックしたときにポップアップが出ると思います。
そこで通信を許可するための操作を行えば問題ありません。

ここで誤って「拒否」を選択してしまった場合はWindows Firewallに拒否ルールが追加されてしまいます。
その場合は、Windowsファイアウォールの規則を編集し、該当の拒否ルールを削除するようにしてください。
アプリケーションにGNS3やDynamipsが含まれていれば、それが問題のルールだと思います。

まとめ

GNS3周りの主なトラブルと回避方法を紹介しました。
皆様の時間節約につながれば幸いです。