無人アップグレードは、Debian / Ubuntu（およびそれらに基づいた他のGNU / Linuxディストリビューション）の自動更新のネイティブメカニズムです。
デフォルトでは、インストールされた
unattended-upgradesパッケージと構成ファイル
/etc/apt/apt.conf.d/50unattended-upgradesによりシステム上で有効になっており
、セキュリティリポジトリからのみパッケージを更新するように構成さ
れています 。 libsslパッケージ。CVE脆弱性データベースの次の補充の結果として出てきます。
注 ：以降、無人アップグレードは、Ubuntuサーバーエディションのコンテキストで検討されます。これは、他のディストリビューションに「そのまま」適用される可能性が最も高いですが、記事の範囲外に残るいくつかの特性があります。それでは、無人アップグレードが提供する追加機能は何ですか（
既定で含まれているセキュリティ更新プログラムに加えて） 、どのような問題が発生する可能性がありますか？
このメカニズムの名前にある「無人」という言葉は、その文字通りの翻訳において本当に重要です-「無人」。 なぜそう インストール中にパッケージが
.dpkg-newファイルを生成し、パッケージの
.dpkg-newされることを思い出すだけで十分です（インストールされたパッケージの構成のチェックサムがシステムの構成のチェックサムと異なる場合）。 この状況を考慮に入れる必要があります。そうし
ないと、configに
追加したオプションで動作しなくなったソフトウェアの新しいバージョンを取得でき、パッケージをインストールした後、サービス/アプリケーションが起動しません。 したがって、パッケージをリポジトリに収集または借用する場合、そのようなパッケージをインストールしても構成自体は更新されないことに注意してください。たとえば、バージョン構成に互換性がない
場合（セキュリティ修正よりも重要な更新の場合に関係します） 、非常に不快になることがあります誰もが長い間寝ていて、パッケージがサーバーのヒープ上に展開され、「すべてが壊れた、ボス！」という状況です。
無人アップグレードパッケージの応答時間といえば、アップデートの確認とUbuntu / Debianシステムへのインストールは
/etc/cron.daily/aptで定義され
/etc/cron.daily/aptます。 ファイルは
/etc/crontabから起動され、デフォルトは早朝（06:25）です。
リポジトリ/ PPAアプリケーション
練習に移りましょう。 次の問題がありました。1つのパッケージがすべてのサーバーにインストールされましたが、ネイティブバージョンではなく、特定の変更が加えられました。 どうする 明らかなオプションは次のとおりです。
- 「数時間、訓練生の一人をのろって、彼に転がしてみましょう！」-これは訓練生にとって有用であることが証明されるかもしれませんが、訓練の段階でシステムを操作し、彼がまったく適切に仕事をする方法を知らないことを条件とします。 さらに、それは本当に呪いに変わります。 さらに、結果は私たちが望むよりも人的要因に依存します。
- 「Chef / Puppet / Ansible / ...！を使ってどこでもロールアウトする」というのは素晴らしいアイデアですが、当時の状況ではそうではありません。 1つのパッケージのために、ドラゴンを倒す必要があります。 選択した構成管理システムに多くのマシンを入力します。
- この記事は無人アップグレードに専念しているため、多くの時間を費やすことなく問題を解決する別の方法を提供するのはこのメカニズムであると推測するのは簡単です...
確かに、無人アップグレードの構成により、選択したリポジトリ（たとえば、信頼できる
正当な理由があるPPA）のパッケージのすべての更新の自動受信をアクティブ化できます。 このすべての自動モチベーションを最小限のレベルで機能させるには、ターゲットマシンで
/etc/apt/apt.conf.d/51unattended-upgrades-custom configを作成するだけで十分です。この行には3行しかありません。
Unattended-Upgrade::Allowed-Origins { "Origin:Suite"; };
独自のリポジトリがある場合、
Originと
Suiteという単語は、少なくとも「どこかですでに見た場所」というカテゴリからの関連付けを引き起こすはずです。 このようなパラメーターは、パッケージを更新する必要があるマシン自体のリポジトリ（
*_InReleaseファイル）で
*_InReleaseできます。 有名な
ppa:nginx/stable ：
$ head -10 /var/lib/apt/lists/ppa.launchpad.net_nginx_stable_ubuntu_dists_trusty_InRelease -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Origin: LP-PPA-nginx-stable Label: NGINX Stable Suite: trusty Version: 14.04 Codename: trusty Date: Sat, 11 Feb 2017 21:55:33 UTC Architectures: amd64 arm64 armhf i386 powerpc ppc64el
次の2つのパラメーターがあります。
Origin -リポジトリの「起源」。メンテナーまたはリポジトリ自体の名前を示す場合があります。Suite -配布ブランチ。 例：安定版、Debian向けのテスト、またはUbuntu向けの信頼できるxenial。
注 ：Release / InReleaseファイルおよびそれらで使用されるパラメーターの詳細なドキュメントについては、 wiki.debian.orgを参照してください。したがって、独自のパッケージリポジトリがある場合は、これらのパラメーターを追加する必要があります。 その結果、この
nginx/stable PPAの例では、すべてのパッケージの無人アップグレードを許可する構成は次のようになります。
Unattended-Upgrade::Allowed-Origins { "LP-PPA-nginx-stable:trusty"; };
新しいOSインストールを展開するときに必要なすべての構成ファイルを作成して、これらの設定を（あなたに最も近い方法および/またはすでに使用されている方法で）自動化することは論理的です。 また、次のように、無人アップグレードの次回の起動の動作を確認できます。
$ unattended-upgrade -v --dry-run
ここのフラグは単純です：
--dry-runより冗長にするため、および
--dry-run変更を適用しないため。 試運転を行うと、このソリューションには
欠点があることがすぐにわかります。
- パッケージのインストールに対話性が必要な場合、つまり ユーザーの介入（特にこれを長期間行っていないために大規模なシステム更新を行っている場合は特に重要です）-無人アップグレードでは何も起こりません。
- PPAからのnginxの自動更新の例は、パッケージの更新に「dirty Harry」という名前を渡したい場合を除き、実際の運用環境ではチェックしないでください。 繰り返しますが、ユーティリティの名前を覚えておいて、実際に監視を必要としないもののみを更新できることに注意してください。 たとえば、ライブラリ（少なくともここでlibcと壊れたDNSリゾルバーを使用したUbuntuのダンスを思い出すと落とし穴があります ）と、構成を必要とせずにオンデマンドで実行されるソフトウェア（atop、htopなど）。
特定のPPAを無人アップグレードに追加することにも適用されないが、実際に複数回遭遇したもう1つの「逆の」例は、PostgreSQLのセキュリティ更新です。 Ubuntu Serverの標準構成（つまり、無人アップグレードによるセキュリティ更新プログラムのみのインストール）では、このDBMSの重要な脆弱性の自動更新により、誰もが期待していなかったときに
再起動しました。 この動作がケースで予期しない（望ましくない）ことが判明した場合は、以下の
Package-Blacklistオプションを参照してください。
追加機能
/etc/apt/apt.conf.d/50unattended-upgrades 、他の無人アップグレードでできることを確認できます。 多くの設定はありませんが、それらのいくつかは便利です：
Package-Blacklistこの方法で更新することを許可されていないパッケージのリスト。 ここでは、libcでこれを行うための例ですぐに提供されます。別の例は、PostgreSQLで上記で説明されています。 ただし、スケールの反対側では、重要な修正を延期すると、 セキュリティが危険にさらされることに注意してください。AutoFixInterruptedDpkg何らかの理由で最後のインストール/更新プロセスを完了できなかった場合、おそらく手動で状況を修正する必要がありました。 このオプションは同じことを行います。 dpkg --force-confold --configure -a呼び出します。 ここでオプション--force-confoldが指定されていることに注意してください-競合が発生した場合、古いバージョンの構成が保存されることを意味します。MinimalStepsできるだけ更新を実行しません。 SIGUSR1を無人アップグレードプロセスに送信することにより、更新を中止できます。InstallOnShutdownコンピューターをシャットダウンする前に更新プログラムをインストールします。 個人的には、私には悪い考えのようです。 スケジュールされたサーバーの再起動後に死体を取得する必要はありません。MailおよびMailOnlyOnError更新および/またはそれらに関する問題についての手紙の送信先。 電子メールは、標準のMTA sendmailを介して送信されます（環境変数SENDMAIL_BINARY ）。 残念ながら、文字のみで、ここでいくつかのAPIに対してcurlを実行することはできません。Automatic-Reboot -ファイル/var/run/reboot-requiredが存在する場合、インストール完了後に自動的に再起動します。 たとえば、Linuxカーネルパッケージをインストールした後、/ etc / kernel /etc/kernel/postinst.d/update-notifierルールがトリガーされると、ファイル自体が表示されます。 一般的に、「ダーティハリー」のセットからの別のオプション。Automatic-Reboot-Time -誰にも見えない夜間に暗いことをしたい場合...自動リブートの特定の時間を設定します。Acquire::http::Dl-Limitは、すでに一般的なaptパラメーターのセットからAcquire::http::Dl-Limitされています。 更新プログラムのダウンロード速度を制限して、チャネルが詰まらないようにします。
結論
無人アップグレードは、DebianおよびUbuntuベースのディストリビューションに組み込まれている自動更新インストールツールです。 通常、対応するリポジトリからセキュリティ更新プログラムをインストールするために使用されますが、アプリケーションを他のリポジトリに拡張するのは簡単です。 このツールは、パッケージに組み込まれたインストールと更新が簡単なプログラムとスクリプトのサポートに役立ちます。実装には、リポジトリ自体と、更新されたマシンの構成の数行のみが必要です。
ただし、このツールのシンプルさは指で叩かないという意味ではないことを忘れないでください：このアクションの安全性が100％確信できない場合は、複雑なサービスまたは重要なサービスの自動更新を設定しないでください。これは、あなたとあなたの睡眠時間に影響しません同僚。