Ubuntuでの無人アップグレードの理論と実践

無人アップグレードは、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つのパッケージがすべてのサーバーにインストールされましたが、ネイティブバージョンではなく、特定の変更が加えられました。 どうする 明らかなオプションは次のとおりです。





確かに、無人アップグレードの構成により、選択したリポジトリ(たとえば、信頼できる正当な理由がある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つのパラメーターがあります。





: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を無人アップグレードに追加することにも適用されないが、実際に複数回遭遇したもう1つの「逆の」例は、PostgreSQLのセキュリティ更新です。 Ubuntu Serverの標準構成(つまり、無人アップグレードによるセキュリティ更新プログラムのみのインストール)では、このDBMSの重要な脆弱性の自動更新により、誰もが期待していなかったときに再起動しました。 この動作がケースで予期しない(望ましくない)ことが判明した場合は、以下のPackage-Blacklist



オプションを参照してください。



追加機能



/etc/apt/apt.conf.d/50unattended-upgrades



、他の無人アップグレードでできることを確認できます。 多くの設定はありませんが、それらのいくつかは便利です:





結論



無人アップグレードは、DebianおよびUbuntuベースのディストリビューションに組み込まれている自動更新インストールツールです。 通常、対応するリポジトリからセキュリティ更新プログラムをインストールするために使用されますが、アプリケーションを他のリポジトリに拡張するのは簡単です。 このツールは、パッケージに組み込まれたインストールと更新が簡単なプログラムとスクリプトのサポートに役立ちます。実装には、リポジトリ自体と、更新されたマシンの構成の数行のみが必要です。



ただし、このツールのシンプルさは指で叩かないという意味ではないことを忘れないでください:このアクションの安全性が100%確信できない場合は、複雑なサービスまたは重要なサービスの自動更新を設定しないでください。これは、あなたとあなたの睡眠時間に影響しません同僚。



All Articles