著者 Rocky Linux/AlmaLinuxでdnf-automaticを自動設定する方法
Rocky LinuxやAlmaLinuxでdnf-automaticを使い、セキュリティ更新を自動化する手順を解説します。systemdタイマーの設定やメール通知、再起動ポリシーの制御方法まで、運用に役立つ具体的な設定例を紹介します。
Rocky Linux および AlmaLinux における dnf-automatic の役割
dnf-automatic は、Rocky Linux および AlmaLinux でセキュリティアップデートを自動適用するためのツールです。これは systemd タイマーによって起動される小さなプログラムで、/etc/dnf/automatic.conf を読み込み、その設定に従って処理を実行します。インストールは 1 つのコマンドで完了します。本ガイドの残りの部分では、サーバーを保護するか、あるいは何もせずに待機するかを決定する設定について解説します。
Debian や Ubuntu から移行した場合、これは Ubuntu VPS における unattended-upgrades と同じ役割を担います。ただし、他のすべての違いよりも重要な点が 1 つあります。それは、パッケージマネージャーにとって「セキュリティ」という言葉が何を意味するかです。Ubuntu では、これは独立したアーカイブポケットとして存在します。一方、RHEL 系では公開されたアドバイザリに付随するメタデータであり、このメタデータが欠落していたり、古くなっていたりする可能性があります。アドバイザリデータのないリポジトリを dnf-automatic に指定した場合、何もインストールされず、成功したと報告されるだけになります。
本ガイドは、2026 年 8 月時点で DNF 4（RHEL 系で採用されているパッケージマネージャー）を使用する Rocky Linux 9 および AlmaLinux 9 を対象としています。バージョン 10 のリリースでは DNF5 に移行し名称が変更されるため、それについては末尾付近のセクションで個別に解説します。以下の各コマンドは、自身のサーバーで実行するものであり、その横に期待される出力を記載しています。
dnf-automatic のインストールと設定ファイルの確認
自動更新の有効化は、新しい VPS のセットアップにおける初期設定の一部として、root 以外のユーザー作成とファイアウォールの設定直後に行うべき作業です。ファイアウォールの設定がまだであれば、Rocky Linux や AlmaLinux に標準搭載されている firewalld を使用してください。SSH ポートと Web サイトが待ち受けるポートを許可し、再起動後も設定が維持されるようにします。
sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timersystemctl is-enabled は、新規インストール直後には disabled を出力します。パッケージをインストールしただけでは何も開始されないためです。「dnf-automatic を導入済み」であるにもかかわらず、一度も更新が適用されていないサーバーの多くはこれが原因です。
DNF のバージョンは、あるオプションの設定において重要です。reboot 設定は DNF 4.15 でアップストリームに追加され、Red Hat は 2023 年 11 月の勧告 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-pagerジャーナルには、実行時に検討された内容と実際に行われた処理が記録されます。また、コマンドラインから特定の動作を強制することも可能です。この場合、その実行時に限りファイルの設定が上書きされます。
sudo dnf-automatic --downloadupdates --no-installupdatesRocky および Alma における upgrade_type = security の真の意味
DNF はバージョン番号を比較してセキュリティアップデートかどうかを判断しているわけではありません。リポジトリ内に公開されている updateinfo.xml というメタデータファイルを読み取ります。このファイルには、各アドバイザリが修正対象とするパッケージがリスト化されています。AlmaLinux はこれを ALSA アドバイザリとして、Rocky は RLSA として公開しています。upgrade_type = security はこのメタデータからフィルタを作成し、一致するパッケージのみをアップグレードします。
これには、多くのユーザーが驚く2つの結果が伴います。
第一に、メタデータがなければアップデートは行われません。リポジトリに 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 は両者ともデータを公開しているため、このリストが空であれば、それは正当な結果です。一方、CentOS Stream はこのデータを一切公開していません。
第二に、セキュリティモードは最小限の変更を行うわけではありません。dnf-automatic はセキュリティフィルタを追加した上で通常のアップグレードパスを実行します。そのため、アドバイザリで指定されたパッケージはリポジトリ内の最新バージョンへ更新され、その依存関係も同時に引き込まれます。アドバイザリを修正する最小限のバージョンのみを適用するような小規模な更新は、dnf upgrade-minimal --security を手動で実行する場合のみ可能です。dnf-automatic にはそのような設定はありません。
Rocky に関してはもう一点注意が必要です。Rocky は Red Hat のデータから独自のパイプラインを通じてエラッタを生成していますが、そのパイプラインが遅延することがあります。2025 年 9 月には、Rocky 9 BaseOS の updateinfo.xml が 2024 年 12 月から更新されておらず、--security に最近のアドバイザリが反映されていないという報告があり、Rocky スタッフも既知の問題として認めました。upgrade_type = security に依存している場合は、アドバイザリリストと最近の RLSA アナウンスを適宜照合してください。変更管理よりも網羅性が重要な環境では、upgrade_type = default を任意のスケジュールで実行する方が安全です。
実際に実行を担う systemd タイマー
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timerlist-timers を実行すると、1 行の出力と約 1 日後の NEXT 時刻が表示されるはずです。テーブルが空であればタイマーは有効化されておらず、ジョブは実行されません。
標準で提供されるタイマーは *-*-* 6:00 に起動し、RandomizedDelaySec=60m と Persistent=true を使用します。ランダムな遅延により負荷が 1 時間に分散されるため、すべてのサーバーが同時にミラーサイトへアクセスすることはありません。Persistent=true は、06:00 に電源がオフだったマシンが起動した直後に未実行のジョブを実行し、その日の実行をスキップしないようにする設定です。
スケジュールを変更する場合はドロップインファイルを使用してください。標準のユニットファイルを直接編集してはいけません。パッケージのアップグレードによって /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 カラムを読み取ってください。このドロップインのルールは、systemd サービスおよびタイマーユニットの作成で解説している他のスケジュール設定にも適用されます。
ここで注意点があります。このパッケージには、dnf-automatic-notifyonly.timer、dnf-automatic-download.timer、dnf-automatic-install.timer という 3 つのタイマーが同梱されています。それぞれがコマンドラインフラグを付与して同じプログラムを起動しますが、これらのフラグは設定ファイルの download_updates や apply_updates を上書きします。dnf-automatic.timer に加えてこれらの一つを有効にすると、ジョブが 2 つの異なる挙動で 2 回実行されることになり、設定ファイルが無視されているように見えます。タイマーを有効化したら、以下を確認してください。
systemctl list-unit-files 'dnf-automatic*'インストール日時を確認する方法
emit_via の [emitters] セクションでレポート機能を制御します。systemd 環境では stdio エミッターがジャーナルへ書き込みを行います。これは追加のインストールを必要としないため、信頼性の高い選択肢です。
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 はサービスを再起動しません
パッケージをインストールするとディスク上のファイルは置き換わります。しかし、実行中のプロセスは古いコードをメモリ上に保持し続けるため、パッチが適用されたライブラリを読み込んでも、先月から起動しているデーモンには何の影響もありません。インストール済み状態と有効な状態との間に生じるこの乖離が、自動パッチ適用においてインストールポリシーだけでなく再起動ポリシーも必要となる理由です。
sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r-s は、起動後にファイルが変更された systemd サービスの一覧を表示します。-r は一つの問いに答え、以下のいずれかのブロックを出力します。
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 といった固定のパッケージリストをチェックするものです。前回の起動後にこれらのいずれかがインストールされた場合、最初の回答が返されます。再起動が必要な他のパッケージがある場合は、/etc/dnf/plugins/needs-restarting.d/ 配下に .conf で終わるファイルを作成し、パッケージ名を追加してください。
スクリプト利用時の注意点として、dnf needs-restarting -r は再起動が必要な場合とコマンド自体が失敗した場合の両方で 0 以外の終了コードを返します。そのため、終了ステータスだけで状況を判断することはできません。出力されたテキストを確認してください。
サービスの再起動は影響範囲が小さく、通常は適切な選択です。SSH デーモンの再起動を行う際は、設定ミスによる締め出しを防ぐため、既に開いている別の SSH セッションから実行してください。カーネルの更新については、実行中のカーネルをその場で置き換えることはできないため、再起動が必要です。その日のアップデートを「再起動が必要なもの」と「サービスの再起動のみで済むもの」に分類したい場合は、どのアップデートに再起動が必要で、どれがサービスの再起動のみで済むか を参照し、パッケージごとに確認してください。
コンテナは別個のケースです。dnf-automatic はホスト側のパッケージにパッチを適用しますが、イメージ内に組み込まれたユーザーランドには一切触れません。そのため、Rocky Linux または AlmaLinux 上の Docker Engine を実行しているサーバーでは、実際にトラフィックを処理しているコードに修正を反映させるために、イメージの再取得とコンテナの再作成が必要です。
サーバーを自動再起動させるべきか？
[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 のまま運用し、ジャーナルを確認した上で手動で再起動を行ってください。
Rocky、AlmaLinux、CentOS Stream：それぞれの違い
Rocky 9 および AlmaLinux 9 では、設定ファイルのパスや unit 名に至るまで、上記の内容はすべて同一です。両者ともエラッタを公開しているため、upgrade_type = security でフィルタリング可能なデータが存在します。前述した Rocky の古いエラッタは、両者の日常的な挙動が異なる数少ない点の一つです。そのため、サーバーを構築する前に、両者を分かつ互換性の約束と古い CPU へのサポートを比較検討してください。
CentOS Stream は例外であり、扱いが困難です。Stream のリポジトリには updateinfo.xml が含まれていないため、セキュリティフィルタは機能せず、実行のたびに No security updates needed と報告されます。Stream では upgrade_type = default を使用し、すべてのアップデートを適用する運用を受け入れる必要があります。また、Stream は RHEL よりも先行して開発が進むため、Rocky や AlmaLinux と比較して設定の変更頻度が高くなります。この違いはパッケージングの偶然ではなく、2020 年に Red Hat が CentOS を RHEL のローリングプレビュー版へと転換した結果であり、Rocky Linux と AlmaLinux が誕生した理由そのものです。
Rocky 10 および AlmaLinux 10 では DNF5 に移行したため、名称が変更されています。アップストリームの DNF5 ドキュメントによると、タイマーは dnf5-automatic.timer となり、デフォルト設定は /usr/share/dnf5/dnf5-plugins/automatic.conf に配置され、ユーザーによる上書きは引き続き /etc/dnf/automatic.conf で行います。download_updates はデフォルトで no ではなく yes となり、upgrade_type として distro-sync が追加されました。アドバイザリのクエリは 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 を出力します。パッケージはインストールされましたが、タイマーはインストールされていません。
ジョブは実行されるが何もインストールされない。 ジャーナルに No security updates needed, but 3 updates available が記録されます。セキュリティフィルターが何も一致させなかったのは、保留中のものにアドバイザリが含まれていないか、リポジトリがアドバイザリデータを公開していないことが原因です。
設定が無視されているように見える。 DNF はデバッグレベルで automatic.conf 内の不明なオプションをログに記録し、デフォルト値を使用します。そのため、キーのスペルミスは何も変更せず、警告も出しません。apply_update = yes と記述しても apply_updates は no のままとなり、サーバーはダウンロードを永遠に繰り返しますが、インストールは行われません。編集後は必ず sudo systemctl start dnf-automatic.service を実行し、ファイルの内容を信頼するのではなくジャーナルを確認してください。
ジョブが1日に2回実行される。 2つのタイマーが有効になっています。systemctl list-unit-files 'dnf-automatic*' でどちらが有効かを確認してください。余分なタイマーが設定ファイルよりも優先されるフラグを渡している可能性があります。
メールが届かない。 email エミッターのために 25 番ポートで待機しているものがないか、send_error_messages が no のままであり、報告すべき内容がエラーのみであった可能性があります。
パッチを適用したサービスが古いバージョンを報告する。 ディスク上のファイルは新しいものですが、メモリ上のプロセスが古いままです。dnf needs-restarting -s で再起動が必要なサービスを確認してください。
FAQ
Rocky Linuxで dnf-automatic はセキュリティアップデートのみをインストールしますか？
upgrade_type = security を /etc/dnf/automatic.conf 内で設定し、かつリポジトリがエラッタメタデータを公開している場合にのみ可能です。Rocky Linux と AlmaLinux は両者ともメタデータを公開しているため、フィルタがアドバイザリと照合できます。デフォルト設定は upgrade_type = default であり、apply_updates = yes が実行されると利用可能なすべてのアップデートをインストールします。
なぜ dnf-automatic は「セキュリティアップデートは不要だが、3件のアップデートがある」と報告するのですか？
DNF はリポジトリから updateinfo.xml を読み取り、各アドバイザリに記載されたパッケージ情報に基づいてセキュリティアップデートを判定します。このメタデータが欠落または古い場合、セキュリティフィルタは何も検知しませんが、通常のアップデートは保留されたままとなり、そのメッセージが表示されます。エラッタを一切公開していない CentOS Stream では想定通りの挙動です。Rocky Linux や 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 を実行し、[Timer] セクションを追加します。まず空の OnCalendar= 行を記述し、その後にスケジュール（例: OnCalendar=*-*-* 03:30）を記述してください。空行が必要な理由は、OnCalendar が設定を累積するためです。空行がないとデフォルトの 06:00 の実行設定が残り、そこに新しいスケジュールが追加されてしまいます。systemctl list-timers dnf-automatic.timer で確認し、NEXT カラムをチェックしてください。
自動パッチ適用を行うサーバーでも確認作業は必要ですか？
はい、必要です。dnf-automatic はパッケージのインストールまでしか行いません。デーモンの再起動は行われず、emit_via で読み取り可能な送信先を指定しない限り、結果の通知も受け取れません。最低限 emit_via を stdio に設定し、send_error_messages を有効にして失敗時にも通知が飛ぶようにしてください。また、パッチ適用期間の終了後に dnf needs-restarting -s を実行し、古いコードで動作し続けているサービスがないか確認してください。