著者 Rocky・AlmaLinuxでdnf-automaticのセキュリティ更新
Rocky Linux 9とAlmaLinux 9でdnf-automaticを設定する方法です。セキュリティ更新だけに絞る設定、systemdタイマー、メール通知、予期しない再起動を避ける方針、DNF 4とDNF5の違いを説明します。
Rocky Linux と AlmaLinux で dnf-automatic が行うこと
dnf-automatic は、Rocky Linux と AlmaLinux でセキュリティ更新を自動適用するための仕組みです。systemd のタイマーによって起動される小さなプログラムで、/etc/dnf/automatic.conf を読み込み、そのファイルで許可された更新を適用します。インストールは 1 つのコマンドで完了します。このガイドでは、システムを保護できるか、何もせずに終了するかを決める設定を説明します。
Debian または Ubuntu から移行した場合、これは Ubuntu VPS で unattended-upgrades が行う処理と同じ役割です。ただし、他の違いより重要な違いがあります。それは、パッケージマネージャーにおける「security」の意味です。Ubuntu では、セキュリティ更新は別のアーカイブポケットとして提供されます。RHEL 系では、公開されたアドバイザリに付随するメタデータとして提供されます。このメタデータが存在しないか、古い場合があります。アドバイザリーデータのないリポジトリを dnf-automatic の対象にすると、成功を報告しながら何もインストールしません。
このガイドは、2026 年 8 月時点の Rocky Linux 9 と AlmaLinux 9 を対象にしています。これらは DNF 4 を使用します（DNF は RHEL 系のパッケージマネージャーです）。10 のリリースでは DNF5 に移行し、名前も変わるため、末尾近くの独立したセクションで説明します。以下の各コマンドは自身のサーバーで実行するものです。実行後に予想される出力も、その隣に示します。
dnf-automatic をインストールし、パッケージに同梱された設定を確認する
自動更新の有効化は、新しい VPS の最初の 10 分に行う初期設定の一部です。root 以外のユーザーとファイアウォールを設定した直後に実施します。
sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer新規インストール直後に systemctl is-enabled を実行すると、disabled と表示されます。パッケージをインストールしても、何も起動しないためです。これは、「dnf-automatic がインストールされている」サーバーで更新が一度も適用されていない最も一般的な理由です。
このオプションには DNF のバージョンが関係します。reboot 設定は upstream の DNF 4.15 で追加され、Red Hat は 2023 年 11 月に advisory RHBA-2023:6645 を通じて dnf-4.14.0-6.el9 にバックポートしました。Rocky 9 と AlmaLinux 9 はこのパッケージを再ビルドしているため、最新のシステムにはこの設定があります。一方、2023 年以降更新していないシステムにはありません。
設定ファイルは /etc/dnf/automatic.conf です。同梱ファイルには、このビルドが認識するすべてのオプションがデフォルト値とともにコメント付きで記載されています。編集する前に一度確認してください。このファイルが、使用中のバージョンにおける唯一の基準です。
処理を決める 2 つのスイッチ
download_updates と apply_updates が、[commands] セクションの動作を決めます。EL9（Rocky 9 と AlmaLinux 9 の共通基盤である enterprise Linux 9）では、どちらもデフォルトで no です。そのため、編集せずに有効化した dnf-automatic は、利用可能な更新を通知するだけです。
noが両方: dnf-automatic は利用可能な更新を報告しますが、システム上では何も変更しません。download_updates = yesとapply_updates = no: パッケージを DNF キャッシュに取得します。その後のインストールは高速で、ネットワーク接続も必要ありません。ただし、その夜に変更は適用されません。yesとupgrade_type = default: セキュリティ更新かどうかに関係なく、利用可能な更新をすべてインストールします。yesとupgrade_type = security: セキュリティアドバイザリーで指定されたパッケージだけをインストールします。
インターネットに公開する VPS では、次の設定から始めるのが妥当です。
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = nevernetwork_online_timeout は、実行時に機能しているネットワークを待つ秒数です。起動直後のサーバーでは重要です。random_sleep は、多数のマシンに負荷を分散するための古い方式です。現在はタイマーがその役割を担います。systemctl cat dnf-automatic.service を実行すると、提供されているサービスが渡す正確なフラグを確認できます。
06:00 まで待たずに、ファイルが想定どおり動作することを確認します。
sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pagerjournal には、実行時に検討された内容と実行された処理が表示されます。コマンドラインから動作を 1 つ指定して強制することもできます。この指定は、その実行時だけファイルの設定を上書きします。
sudo dnf-automatic --downloadupdates --no-installupdatesRocky と AlmaLinux で upgrade_type = security が本当に意味すること
DNF は、バージョン番号を比較して更新がセキュリティ更新かどうかを判定するわけではありません。リポジトリ内で公開されている updateinfo.xml というファイルのエラータメタデータを読み込みます。各アドバイザリには、それを修正するパッケージが一覧化されています。AlmaLinux はこれらを ALSA アドバイザリとして公開し、Rocky は RLSA として公開しています。upgrade_type = security は、このメタデータからフィルターを作成し、一致したパッケージだけを更新します。
ここから、どちらも意外に思われやすい2つの結果が生じます。
1つ目は、メタデータがなければ更新もないことです。リポジトリに updateinfo.xml が含まれていない場合、フィルターは何にも一致せず、実行はジャーナルに次の行を残して終了します。
No security updates needed, but 3 updates availableシステムにはパッチが適用されていませんが、失敗も報告されません。次のコマンドで確認できます。
dnf updateinfo list --security
dnf check-updatednf check-update がパッケージを一覧表示する一方で、dnf updateinfo list --security が何も出力しない場合、保留中の更新にアドバイザリが付いていないか、リポジトリに読み取るアドバイザリデータがありません。Rocky と AlmaLinux はどちらもこのデータを公開しているため、この2つでは空の一覧が示す内容は通常、そのまま事実です。CentOS Stream はこのデータをまったく公開していません。
2つ目は、セキュリティモードが最小限の変更を意味するわけではないことです。dnf-automatic はセキュリティフィルターを追加した後、通常の更新処理を実行します。そのため、アドバイザリに記載されたパッケージはリポジトリ内の最新バージョンまで更新され、依存関係も一緒に取得されます。アドバイザリを修正する最初のバージョンまでだけ更新する、より小さな変更は dnf upgrade-minimal --security を手動で実行した場合です。dnf-automatic には、そのための設定はありません。
Rocky には、もう1つ注意点があります。Rocky は独自のパイプラインを通じて Red Hat のデータからエラータを生成していますが、そのパイプラインには遅延が生じています。2025年9月、ユーザーから Rocky 9 BaseOS の updateinfo.xml が2024年12月以降更新されておらず、--security に最近のアドバイザリが含まれていないとの報告がありました。Rocky のスタッフも、これを既知の問題として確認しています。upgrade_type = security に依存している場合は、アドバイザリ一覧を最近の RLSA 発表と定期的に照合してください。変更管理よりも適用範囲を重視するシステムでは、upgrade_type = default を選択したスケジュールで実行する方が安全です。
実際に実行する systemd timer
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timerlist-timersには、約1日後の NEXT時刻を示す行が1行表示されます。空のテーブルは timer が有効になっていないことを意味するため、ジョブは実行されません。
配布されている timer は、*-*-* 6:00に RandomizedDelaySec=60mと Persistent=trueを指定して実行されます。ランダム遅延により、複数のサーバーが1時間の範囲に分散されます。そのため、すべてのサーバーが同じ秒にミラーへアクセスすることはありません。Persistent=trueにより、06:00 に電源がオフだったマシンでも、起動後すぐに未実行のジョブが実行されます。その日のジョブがスキップされることはありません。
drop-in でスケジュールを変更します。配布された unit は編集しないでください。パッケージのアップグレードによって、/usr/lib/systemd/system以下のファイルが置き換えられるためです。
sudo systemctl edit dnf-automatic.timer[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m空の OnCalendar= 行は必須です。OnCalendarは累積されるため、このリセットがないと 06:00 のエントリが残ったまま別のエントリが追加され、ジョブが1日に2回実行されます。systemctl list-timers dnf-automatic.timerで結果を確認し、NEXT列を読み取ります。その他のスケジュールにも同じ drop-in のルールが適用されます。詳細は systemd service と timer unit の作成を参照してください。
ここで注意が必要です。パッケージには、さらに3つの timer が含まれています。dnf-automatic-notifyonly.timer、dnf-automatic-download.timer、dnf-automatic-install.timerです。それぞれがコマンドラインフラグ付きで同じプログラムを起動し、そのフラグが設定ファイルの download_updatesと apply_updatesを上書きします。dnf-automatic.timerの隣でいずれかを有効にすると、ジョブが異なる動作で2回実行されます。これは、設定ファイルが無視されている場合とまったく同じように見えます。timer を1つ有効にして、次を確認します。
systemctl list-unit-files 'dnf-automatic*'インストール時期を確認する方法
emit_via セクションの [emitters] で、レポート方法を制御します。systemd では stdio エミッターが journal に書き込みます。追加のソフトウェアを必要としないため、これが信頼できる方法です。
sudo journalctl -u dnf-automatic.service --since -7d --no-pagermotd エミッターはレポートを /etc/motd に書き込み、ファイルの内容を置き換えます。そこにログインバナーを保持している場合は、このエミッターを指定しないでください。
email エミッターは、email_port 上の email_host への SMTP（simple mail transfer protocol）接続を開きます。デフォルト値はそれぞれ localhost と 25 です。新規の VPS では、そこを待ち受けるサービスがないため、接続が拒否され、メールは送信されません。利用する前に ss -lnt | grep ':25' を実行してください。出力が空の場合は、リレー専用の Postfix を設定してください。メールが正常に機能すると、件名は Updates applied on 'web01'. になります。名前は system_name から取得されます。
それ以外の場合、command エミッターは標準入力経由で、ユーザーが指定したプログラムにレポートを渡します。
[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes
[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}send_error_messages のデフォルト値は no です。この場合、実行に失敗しても何もレポートされません。有効にしてください。成功だけを通知するパッチ適用システムは、存在しないよりも悪いものです。通知がないと、正常に動作しているように見えるためです。
dnf-automatic はサービスを再起動しません
パッケージをインストールすると、ディスク上のファイルが置き換わります。すでに実行中のプロセスは古いコードをメモリ上に保持するため、先月起動した daemon には、更新されたライブラリをインストールしても効果がありません。インストール済みの状態と実際に有効な状態の間に差が生じるため、無人パッチ適用にはインストール方針だけでなく、再起動方針も必要です。
sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r-s は、起動後にファイルが変更された systemd サービスを一覧表示します。-r は 1 つの質問に答え、2 種類のブロックのいずれかを表示します。
Core libraries or services have been updated since boot-up:
* kernel
Reboot is required to fully utilize these updates.No core libraries or services have been updated since boot-up.
Reboot should not be necessary.-r は詳細な分析を行うものではありません。固定されたパッケージ一覧を確認します。一覧に含まれるのは kernel、kernel-core、kernel-rt、glibc、linux-firmware、systemd、dbus、dbus-broker、dbus-daemon、microcode_ctl です。いずれかが前回の boot 後にインストールされている場合、最初の回答が表示されます。ほかのソフトウェアでも再起動しないと変更が有効にならない場合は、/etc/dnf/plugins/needs-restarting.d/ 配下の .conf で終わるファイルにパッケージ名を追加します。
スクリプトで使用する場合は注意が必要です。dnf needs-restarting -r は、再起動が必要な場合だけでなく、コマンド自体が失敗した場合にも non-zero で終了します。そのため、終了ステータスだけでは両者を区別できません。出力テキストを確認してください。
サービスの再起動は、より影響の小さい操作であり、通常はこちらが適切です。SSH daemon を再起動する場合は、すでに開いている 2 つ目の SSH セッションから実行してください。設定に問題があっても、接続不能になることを防げます。新しい kernel の場合は、再起動だけが有効なケースです。実行中の kernel は、その場で置き換えられないためです。
サーバーは自動的に再起動すべきですか？
[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'reboot = neverがデフォルトです。when-changedは、適用された更新の後に毎回再起動します。when-neededは、needs-restarting -rによる確認でコアパッケージが置き換えられた場合にのみ再起動します。これは、独自に設定したタイマーの時間帯と組み合わせる構成で、多くの単一サーバー運用者に適しています。デフォルトのreboot_commandでは、shutdownを通じて、ログイン中のユーザーに5分前に警告します。この時間は延長できます。
これを有効にする前に、2つの点を確認してください。依存するすべてのサービスが、ブート時に自動的に起動する必要があります。手動で起動したDocker Compose スタックでは、ここが通常の抜けになります。また、プロバイダーからコンソールまたはレスキューアクセスを利用できる必要があります。カーネルが起動しない場合、SSH経由では修復できないためです。どちらかが欠けている場合は、reboot = neverを維持し、journalを確認してから手動で再起動してください。
Rocky、AlmaLinux、CentOS Stream の違い
Rocky 9 と AlmaLinux 9 では、上記の内容は設定パスや unit 名まで完全に同じです。どちらも errata を公開しているため、upgrade_type = security にはフィルタリング対象のデータがあります。
CentOS Stream は例外で、対応が難しいケースです。Stream のリポジトリには updateinfo.xml がないため、セキュリティフィルタは一致せず、毎回 No security updates needed が報告されます。Stream では upgrade_type = default を使用し、すべての更新を適用することを受け入れてください。Stream は RHEL より先行して更新されるため、同じ設定でも Rocky や AlmaLinux より Stream の環境では変更量が大きくなります。
Rocky 10 と AlmaLinux 10 は DNF5 に移行したため、名称が変更されています。上流の DNF5 ドキュメントでは、タイマーを dnf5-automatic.timer とし、提供時のデフォルト値を /usr/share/dnf5/dnf5-plugins/automatic.conf に配置します。ユーザーによる上書き設定は引き続き /etc/dnf/automatic.conf に配置します。また、download_updates のデフォルト値を no から yes に変更し、distro-sync を upgrade_type として追加しています。アドバイザリのクエリは dnf advisory list で、updateinfo はエイリアスとして残されています。9 向けのガイドからパッケージ名や unit 名をコピーする前に、実際に使用しているリリースで何がインストールされているかを確認してください。
dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'このトピックに関する公開済みのガイドの多くは、現在も Rocky 8 のみを対象にしています。これらのガイドが書かれた後にオプションは増えているため、古い記事をそのまま信頼せず、自分の環境にあるコメント付きファイルを確認してください。
障害のパターンと表示される文字列
何も実行されない。 systemctl list-timers dnf-automatic.timer は空のテーブルを表示し、systemctl is-enabled dnf-automatic.timer は disabled を表示します。パッケージはインストールされていますが、タイマーが作成されていません。
ジョブは実行されるが、何もインストールされない。 journal に No security updates needed, but 3 updates available が記録されます。保留中の更新にアドバイザリが付いていないか、リポジトリがアドバイザリーデータを公開していないため、セキュリティフィルターが何も検出していません。
設定が無視されているように見える。 DNF はデバッグレベルで automatic.conf に未知のオプションを記録し、デフォルト値を使用します。そのため、キーを誤記しても設定は変わらず、警告も表示されません。apply_update = yes を記述し、apply_updates が no のままである場合、サーバーは更新をダウンロードし続けるだけで、インストールは一度も行いません。編集後は必ず sudo systemctl start dnf-automatic.service を実行し、ファイルを信用するのではなく journal を確認してください。
ジョブが 1 日に 2 回実行される。 2 つのタイマーが有効になっています。systemctl list-unit-files 'dnf-automatic*' で有効なタイマーを確認できます。余分なタイマーは、設定ファイルより優先されるフラグを渡しています。
メールが届かない。 email emitter 用に port 25 で待ち受けているプロセスがないか、send_error_messages がまだ no のいずれかです。報告対象になるのはエラーだけです。
パッチ適用後もサービスが古いバージョンを報告する。 ディスク上のファイルは新しくても、メモリ上のプロセスは古いままです。dnf needs-restarting -s で再起動が必要なサービスを確認できます。
FAQ
dnf-automatic は Rocky Linux でセキュリティ更新のみをインストールしますか？
upgrade_type = security を /etc/dnf/automatic.conf に設定した場合に限り、かつリポジトリが errata メタデータを公開している場合に限ります。Rocky Linux と AlmaLinux はどちらも公開しているため、フィルターで照合するアドバイザリが存在します。出荷時のデフォルトは upgrade_type = default で、apply_updates = yes になると利用可能なすべての更新をインストールします。
dnf-automatic が「セキュリティ更新は不要ですが、3 件の更新が利用可能です」と報告するのはなぜですか？
DNF は、リポジトリから updateinfo.xml を読み取り、セキュリティ更新に該当するものを判断します。各アドバイザリには、その問題を修正するパッケージが記載されています。このメタデータがないか古い場合、セキュリティフィルターは何も照合できません。一方で通常の更新は保留されているため、まさにその行が表示されます。errata をまったく公開しない CentOS Stream では想定された動作です。Rocky または AlmaLinux では、dnf updateinfo list --security と dnf check-update を比較し、メタデータが最新であることを確認してください。
カーネル更新後に dnf-automatic はサーバーを再起動しますか？
明示的に指定しない限り、再起動しません。reboot オプションのデフォルトは never です。reboot = when-needed を設定すると、dnf needs-restarting -r のチェックによって、kernel や glibc などのコアパッケージがブート後に置き換えられたと判定された場合に限り、実行時に再起動します。reboot = when-changed は、適用された更新の種類に関係なく再起動します。どちらも reboot_command を使用します。デフォルトは shutdown -r +5 で、ログイン中のユーザーに警告メッセージを表示します。
dnf-automatic の実行時刻を変更するにはどうすればよいですか？
sudo systemctl edit dnf-automatic.timer を実行し、空の OnCalendar= 行の後にスケジュールを記述した [Timer] セクションを追加します。たとえば OnCalendar=*-*-* 03:30 のようにします。OnCalendar は値を累積するため、空の行が必要です。空の行を省略すると、出荷時の 06:00 の実行が残ったまま、2 つ目の実行が追加されます。systemctl list-timers dnf-automatic.timer で確認し、NEXT 列を読み取ってください。
自動的にパッチを適用するサーバーも確認する必要がありますか？
はい。dnf-automatic はパッケージをインストールして終了します。デーモンを再起動することはありません。また、emit_via に実際に確認している emitter を指定しない限り、確認できる報告もありません。最低限、emit_via を stdio に設定し、失敗も報告されるように send_error_messages を有効にしてください。パッチ適用後のメンテナンス時間が終わったら dnf needs-restarting -s を実行し、古いコードのまま稼働しているサービスを確認します。