なぜ適切なキャッシュを更新し続けるのですか？

Question 1

あなたの質問は少しあいまいです。質問が「なぜapt-get updateを実行するのですか？」なら、答えはaptの更新が時間のかかるプロセスである可能性があるということです。パッケージをインストールするたびにこれを行うと、時間がかなり増えます。通常、1日に1回キャッシュを更新するだけで十分です（理想的には自動化された方法で）。

「明日新しいパッケージをインストールしたい場合は、再度更新するまでサーバーはこれを知りません。私はDebianサーバーでのみこれに気づきました。

この部分についてはよくわかりません。明日、新しいバージョンのユニゾンがリリースされたらどうすればわかりますか？同様に、apt-get updateを1日に1回以上（たとえば、cronスクリプトを介して）実行すると、aptは新しいパッケージがあることを知ります。つまり、新しいパッケージが利用可能であるという事実を自動的に伝えません。パッケージをアップグレードすると、ユーザーが解決する必要があるシステムの安定性の問題が発生する可能性があるため、これには妥当な理由があります。

通常、Debian ベースのシステムでは、徐々に更新されるソフトウェアのバージョンが必ずしも優れているわけではありません。セキュリティ上の問題がある場合、または新しいバージョンに必要な機能がない限り、通常はマイナーバージョンのアップグレードには興味がありません。

Answer

あなたの質問は少しあいまいです。質問が「なぜapt-get updateを実行するのですか？」なら、答えはaptの更新が時間のかかるプロセスである可能性があるということです。パッケージをインストールするたびにこれを行うと、時間がかなり増えます。通常、1日に1回キャッシュを更新するだけで十分です（理想的には自動化された方法で）。

「明日新しいパッケージをインストールしたい場合は、再度更新するまでサーバーはこれを知りません。私はDebianサーバーでのみこれに気づきました。

この部分についてはよくわかりません。明日、新しいバージョンのユニゾンがリリースされたらどうすればわかりますか？同様に、apt-get updateを1日に1回以上（たとえば、cronスクリプトを介して）実行すると、aptは新しいパッケージがあることを知ります。つまり、新しいパッケージが利用可能であるという事実を自動的に伝えません。パッケージをアップグレードすると、ユーザーが解決する必要があるシステムの安定性の問題が発生する可能性があるため、これには妥当な理由があります。

通常、Debian ベースのシステムでは、徐々に更新されるソフトウェアのバージョンが必ずしも優れているわけではありません。セキュリティ上の問題がある場合、または新しいバージョンに必要な機能がない限り、通常はマイナーバージョンのアップグレードには興味がありません。

Question 2

通常、これは、最後のアップデートで得られた正確なバージョン情報が新しいバージョンに置き換えられたため、Debian サーバーで使用できなくなることを意味します。しかし、Squeezeでは、これはあまりにも多くは発生しません（セキュリティアップデートを検討しても）。もう1つのオプションは、/var/lib/apt/listsサーバーで利用可能なパッケージのリスト（apt-get updateにインポートされたディレクトリも含む）をキャッシュするディレクトリを定期的にクリーンアップする奇妙なスクリプト（これらのスクリプトは不明です）を使用することです。不安定であっても実験的なサーバー（少し奇妙に見える）に従わない限り、この場合はパッケージが頻繁に更新されるため、キャッシュリストは非常に迅速に古いものになります。だから私のアドバイスは、apt-get updateインストールプロセスを開始するたびに最初にその呼び出しを実行するように筋肉の記憶を訓練することです。

Answer

通常、これは、最後のアップデートで得られた正確なバージョン情報が新しいバージョンに置き換えられたため、Debian サーバーで使用できなくなることを意味します。しかし、Squeezeでは、これはあまりにも多くは発生しません（セキュリティアップデートを検討しても）。もう1つのオプションは、/var/lib/apt/listsサーバーで利用可能なパッケージのリスト（apt-get updateにインポートされたディレクトリも含む）をキャッシュするディレクトリを定期的にクリーンアップする奇妙なスクリプト（これらのスクリプトは不明です）を使用することです。不安定であっても実験的なサーバー（少し奇妙に見える）に従わない限り、この場合はパッケージが頻繁に更新されるため、キャッシュリストは非常に迅速に古いものになります。だから私のアドバイスは、apt-get updateインストールプロセスを開始するたびに最初にその呼び出しを実行するように筋肉の記憶を訓練することです。

Question 3

ついにこの問題を解決できました。先に推測したように、cron-aptこれが犯人です。またはより具体的に構成します。

私を混乱させた最初のことは、インストールされたcron-aptということです。他のコンピュータにはデフォルトでインストールされていないためです。この問題が発生した VPS プロバイダーのコンピューターでのみ発生しました。スクリプトがすでに同様のメカニズムを提供していると仮定しているため、その存在は混乱しています/etc/cron.daily/apt。いずれにせよ、質問に従って実行すると、cron-aptキャッシュされた情報の量が減ります。

最初は見えませんでした。なぜそのため、cron-apt実際に更新が毎日行われているからです。

oliver@cloud:/$ cat /etc/cron-apt/action.d/0-update
update -o quiet=2

だからどうしたの？

/usr/sbin/cron-aptスクリプトを1行ずつ実行しなければ問題が見つかりませんでした。私はここ$APTCOMMANDに常に何か追加が添付されることを知っています$OPTIONS。結果の呼び出しは次のとおりです。

/usr/bin/apt-get -o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list update -o quiet=2

それで私は/etc/cron-apt/configこの$OPTIONSブロックを見て発見しました。

# General apt options that will be passed to all APTCOMMAND calls.
# Use "-o quiet" instead of "-q" for aptitude compatibility.
#  OPTIONS="-o quiet=1"
# You can for example add an additional sources.list file here.
#  OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"
# You can also set an alternative sources.list file here.
#  OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list -o Dir::Etc::SourceParts=\"/dev/null\""
OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"
# If you want to allow unauthenticated and untrusted packages add the
# following to your options directive.
#  OPTIONS="-o quiet=1 -o APT::Get::AllowUnauthenticated=true -o aptitude::Cmdline::ignore-trust-violations=yes"
# To limit the bandwidth used use the following line. This example limit the
# bandwidth usage to 25 kB/s.
#  OPTIONS="-o Acquire::http::Dl-Limit=25"

糸が飛び出しています。コメントがない方。明らかに、この行はデフォルトでは存在しません（他のシステムでもこの内容をすばやく確認しました）。

不明な場合、これらのオプションを使用する理由は、キャッシュされたソースが毎晩ホワイトリストのコンテンツで上書きされるためです。ただそれら）。

VPS プロバイダーは、これが Debian インストールイメージのカスタマイズであることを確認しました。問題のある設定を削除し、すべてが正常に戻りました。

Answer