この手順で設定する内容と前提条件
この記事の手順を上から実行すると、次の状態になります。セキュリティ更新が毎日自動で適用されます。再起動するかどうかと、その時刻は自分で決めた方針どおりに動きます。適用結果はログで確認できます。不具合が出たパッケージは元のバージョンに戻して固定できます。
対象は、Ubuntu(22.04 LTS / 24.04 LTS)とDebian(12 / 13)のunattended-upgrades、RHEL 8 / 9とその互換ディストリビューション(AlmaLinux、Rocky Linuxなど)のdnf-automaticです。設定ファイルの既定値はバージョンによって変わります。この記事の記述は執筆時点(2026年10月)の内容です。作業前に、手元のファイルの中身を必ず確認してください。dnf5を採用したFedoraなどでは、パッケージ名やタイマー名が異なる場合があります。
作業前に用意するもの
root権限かsudo権限が必要です。リモートのサーバーでは、SSHが切れても操作できる経路も用意してください。クラウドならシリアルコンソール、物理サーバーならIPMIなどです。再起動後に起動しなかった場合、この経路がないと復旧できません。仮想マシンではスナップショットを、物理サーバーではバックアップを取っておきます。可能であれば、本番と同じ構成の検証機で先に数日動かします。
つまずきやすい箇所
つまずきやすい箇所は3つあります。1つ目は、更新対象の指定ミスです。Debianの既定設定では、セキュリティ更新に加えてポイントリリースの更新も対象に入っています。RHEL系の既定値は全更新が対象です。「セキュリティだけ」のつもりで既定のまま有効にすると、想定より多くのパッケージが更新されます。2つ目は再起動です。カーネルや主要ライブラリを更新しても、再起動するまで古いコードが動き続けます。3つ目はロールバックです。古いバージョンがリポジトリに残っていないことがあります。この場合は簡単に戻せません。
適用範囲と再起動の方針を先に決める
設定ファイルを開く前に、2つの方針を決めて記録します。
1つ目は適用範囲です。まずはセキュリティ更新だけを自動化し、機能更新やバグ修正は手動で適用する方法を推奨します。セキュリティ更新は修正範囲が小さく、互換性を壊しにくいためです。データベースのように更新時に慎重な確認が必要なパッケージは、後の節で自動更新から除外します。
2つ目は再起動の扱いです。冗長構成で1台ずつ止められるサーバーなら、深夜の自動再起動を有効にできます。単独で動く業務サーバーでは自動再起動を無効にします。そのうえで「再起動が必要」という状態を監視し、計画停止の時間に手動で再起動します。どちらを選んでも、再起動が必要な状態を放置しないことが前提です。
Ubuntu/Debian:unattended-upgradesを設定する
手順1:インストールして有効化する
Ubuntu Serverでは多くの場合インストール済みです。Debianでは入っていないことがあります。次のコマンドでインストールし、有効化します。
sudo apt update sudo apt install unattended-upgrades apt-listchanges sudo dpkg-reconfigure -plow unattended-upgrades
最後のコマンドの確認画面で「はい」を選ぶと、/etc/apt/apt.conf.d/20auto-upgradesが作成されます。中身が次の2行になっていれば有効です。1行目がパッケージ一覧の毎日更新、2行目が自動適用の毎日実行を意味します。
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";
手順2:対象をセキュリティ更新に絞る
適用範囲は/etc/apt/apt.conf.d/50unattended-upgradesで指定します。UbuntuではUnattended-Upgrade::Allowed-Originsのブロックを確認します。有効な行(先頭が//でない行)が、次のように-securityで終わるものだけになっていれば問題ありません。
"${distro_id}:${distro_codename}-security";
"${distro_id}ESMApps:${distro_codename}-apps-security";
"${distro_id}ESM:${distro_codename}-infra-security";ESMで始まる2行は、Ubuntu Proの延長セキュリティ保守向けです。Ubuntu Proを有効にしていなければ何も適用されないため、残しておいて構いません。-updatesの行がコメントアウトされていることも確認します。
DebianではUnattended-Upgrade::Origins-Patternのブロックを確認します。既定値にはlabel=Debianで終わる行(ポイントリリースの更新)が含まれています。セキュリティ更新だけにする場合は、この行の先頭に//を付けてコメントアウトし、label=Debian-Securityの行だけを残します。サードパーティのリポジトリを対象に加えたい場合は、apt-cache policyの出力に表示されるo=(origin)やa=(archive)の値で指定します。
手順3:自動再起動を設定する
同じファイルの次の項目で再起動を制御します。初期状態ではコメントアウトされています。
Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "03:00"; Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
自動再起動は、更新によって/var/run/reboot-requiredが作られたときだけ実行されます。再起動が必要なかった日には再起動しません。Automatic-Reboot-WithUsersを"false"にすると、ログイン中のユーザーがいるときは再起動しません。ただし、セッションを開いたままにしている人がいると、再起動が永久に保留されます。自動再起動しない方針なら、Automatic-Rebootを"false"のままにします。代わりに、監視ツールで/var/run/reboot-requiredの有無を確認します。
手順4:試行して実行時刻を確認する
設定を保存したら、実際には何も変更しない試行モードで動作を確認します。
sudo unattended-upgrade --dry-run --debug
出力のAllowed origins are:の行に、手順2で残した対象だけが表示されていれば正しい設定です。Packages that will be upgraded:の行には、現在適用待ちのパッケージが表示されます。
自動実行のタイミングはsystemdのタイマーで決まります。apt-daily.timerが一覧を更新し、apt-daily-upgrade.timerが更新を適用します。次の実行時刻はsystemctl list-timers 'apt-daily*'で確認できます。既定では朝6時ごろにランダムな遅延を加えて実行されます。時刻を変える場合はsudo systemctl edit apt-daily-upgrade.timerで上書き設定を作り、次のように記述します。空のOnCalendar=行で既定値を消してから、新しい値を指定する点がポイントです。
[Timer] OnCalendar= OnCalendar=*-*-* 02:00 RandomizedDelaySec=30m
RHEL系:dnf-automaticを設定する
手順1:インストールする
sudo dnf install dnf-automatic
手順2:対象をセキュリティ更新に絞る
/etc/dnf/automatic.confの[commands]セクションを次のように編集します。
[commands] upgrade_type = security download_updates = yes apply_updates = yes
upgrade_typeの既定値はdefaultで、すべての更新が対象です。securityにすると、リポジトリのupdateinfo(セキュリティ勧告の情報)でセキュリティ修正とされた更新だけを適用します。リポジトリがupdateinfoを提供していない場合は、何も適用されません。次のコマンドで、セキュリティ更新が認識されているかを先に確認します。
dnf updateinfo list --security
結果を通知する方法は[emitters]セクションのemit_viaで指定します。stdioならjournalに、emailならメールで届きます。メール通知を使う場合は、サーバーからメールを送れるかを別途確認してください。
手順3:自動再起動を設定する
新しいバージョンのdnf-automaticでは、[commands]セクションのrebootで再起動を制御できます。neverは再起動しない、when-changedは何か更新されたら再起動する、when-neededはカーネルなど再起動が必要な更新があったときだけ再起動する、という意味です。
reboot = when-needed
設定ファイルにrebootの項目がない古いバージョンでは、この機能は使えません。その場合はneeds-restarting -r(dnf-plugins-coreに含まれる)で再起動の要否を確認し、計画した時間に手動で再起動します。終了コードが1なら再起動が必要です。
手順4:タイマーを有効にする
sudo systemctl enable --now dnf-automatic.timer systemctl list-timers 'dnf-automatic*'
使うタイマーはdnf-automatic.timerです。このタイマーはautomatic.confの設定どおりに動作します。似た名前のdnf-automatic-install.timerなどは、設定ファイルのapply_updatesを上書きして動きます。両方を有効にすると動作が分かりにくくなるため、どちらか一方だけを使ってください。実行時刻は、Ubuntuと同じくsystemctl edit dnf-automatic.timerで変更できます。初回はsudo systemctl start dnf-automatic.serviceで手動実行し、次の節のログでエラーがないことを確認します。
適用結果をログで確認する
Ubuntu/Debianでは、/var/log/unattended-upgrades/unattended-upgrades.logに、適用したパッケージの一覧とエラーが記録されます。同じディレクトリのunattended-upgrades-dpkg.logには、インストール処理の詳細な出力が残ります。/var/log/apt/history.logには、apt全体の操作履歴が記録されます。Upgrade:行では更新前と更新後のバージョンが対になっています。この記録は、後でロールバックするときに使います。
RHEL系では、journalctl -u dnf-automatic.serviceで各回の実行結果を確認します。sudo dnf history listには処理ごとにIDが付いた一覧が表示されます。sudo dnf history info ID番号を実行すると、その処理で変わったパッケージとバージョンが分かります。より詳しい記録は/var/log/dnf.logと/var/log/dnf.rpm.logにあります。
導入後の最初の1週間は、毎日ログを確認してください。「更新が0件の日が続く」場合は、設定の誤りを疑います。対象の指定が誤っているか、リポジトリに到達できていない可能性があります。
更新で不具合が出たときにパッケージを戻す
まず、どのパッケージがいつ更新されたかを前節のログで特定します。原因を特定しないまま関係のなさそうなパッケージまで戻すと、別の脆弱性を残すことになります。
Ubuntu/Debianで戻す
apt-cache policy パッケージ名 sudo apt install パッケージ名=戻したいバージョン
apt-cache policyの一覧に戻したいバージョンが表示されれば、2行目のコマンドで戻せます。同じソースから作られる関連パッケージ(例:opensslとlibssl3)は、バージョンをそろえて同時に指定します。そろえないと依存関係のエラーになります。
Ubuntuのリポジトリは、リリース時の版と最新の更新版しか保持していないことが多くあります。間のバージョンは取得できない場合があります。その場合は/var/cache/apt/archives/に古い.debファイルが残っていないかを確認し、残っていればsudo apt install ./ファイル名.debで入れ直します。Debianでは過去のパッケージを保存した公式アーカイブ(snapshot.debian.org)も利用できます。
RHEL系で戻す
sudo dnf history undo ID番号 sudo dnf downgrade パッケージ名
history undoは、指定した処理による変更をまとめて取り消します。1つのパッケージだけを戻すならdowngradeを使います。どちらも、古いバージョンがリポジトリに残っていることが条件です。カーネルは複数の版が並行してインストールされます。そのため、パッケージを戻すのではなく起動するカーネルを切り替えます。sudo grubby --info=ALLで一覧を確認し、sudo grubby --set-default /boot/vmlinuz-起動したい版で既定を変えて再起動します。
バージョンを固定して自動更新から外す
戻したままにすると、翌日の自動更新で再び新しい版が入ります。原因が解決するまで、バージョンを固定します。
Ubuntu/Debianではsudo apt-mark hold パッケージ名で固定します。unattended-upgradesも固定されたパッケージは更新しません。固定中のパッケージはapt-mark showholdで一覧でき、sudo apt-mark unhold パッケージ名で解除できます。恒常的に自動更新から外したいパッケージは、50unattended-upgradesのUnattended-Upgrade::Package-Blacklistに書く方法もあります。この方法なら、手動のaptでは更新できます。
RHEL系ではversionlockプラグインを使います。
sudo dnf install python3-dnf-plugin-versionlock sudo dnf versionlock add パッケージ名 dnf versionlock list sudo dnf versionlock delete パッケージ名
versionlock addは、現在インストールされているバージョンを固定します。ダウングレードを済ませてから実行してください。
固定したパッケージには、以後のセキュリティ修正も適用されません。固定するときは、理由と見直し期限を構成管理の記録に残してください。
運用を始めた後に判断すること
運用開始から1か月を目安に、次の3点を判断します。1つ目は範囲の拡大です。ログに不具合の記録がなく、更新後の動作確認も問題なければ、通常の更新も自動化するかを検討します。2つ目は再起動です。reboot-requiredやneeds-restarting -rが再起動を求めたまま1週間以上たっているなら、自動再起動を有効にするか、計画停止の頻度を上げます。3つ目は固定の解除です。固定中のパッケージは期限ごとに見直し、修正版が出ていれば解除します。
悪用が確認された脆弱性が公表されたときは、自動更新を待たずに手動で適用します。次の実行は最大で約1日後になるためです。各ディストリビューションの公式アドバイザリ(Ubuntu Security Notices、Debian Security Information、Red Hat Product Security)で、修正版の有無と再起動の要否を確認してください。設定項目の詳細はDebian WikiとRed Hat Documentationが一次情報です。