왜 적절한 캐시를 계속 업데이트해야 합니까?

Question 1

귀하의 질문은 약간 모호합니다. 질문이 "왜 apt-get update를 실행해야 합니까?"라면, 대답은 apt 업데이트가 시간이 많이 걸리는 프로세스일 수 있다는 것입니다. 패키지를 설치해야 할 때마다 이 작업을 수행하면 시간이 꽤 많이 추가됩니다. 일반적으로 하루에 한 번 캐시를 업데이트하면 충분합니다(이상적으로는 자동화된 방식으로).

"내일 새 패키지를 설치하려는 경우 다시 업데이트할 때까지 서버는 이에 대해 알지 못할 것입니다. 저는 데비안 서버에서만 이 사실을 알아차렸으며 이를 유발하는 어떤 조정도 알지 못합니다."

이 부분에 대해서는 잘 모르겠습니다. 내일 새로운 버전의 unison이 출시된다면 어떻게 알 수 있다는 겁니까? 마찬가지로 apt-get update를 하루에 한 번 이상(예: cron 스크립트를 통해) 실행하면 apt는 새 패키지가 있음을 알게 됩니다. 즉, 새 패키지를 사용할 수 있다는 사실을 자동으로 알려주지 않습니다. 패키지를 업그레이드하면 때때로 사용자가 해결해야 하는 시스템 안정성 문제가 발생할 수 있으므로 이는 타당한 이유가 있습니다.

일반적으로 Debian 기반 시스템에서는 점진적으로 업데이트되는 소프트웨어 버전이 반드시 더 나은 것은 아닙니다. 보안 문제가 있거나 새 버전에 필요한 기능이 없는 한 일반적으로 마이너 버전 업그레이드에는 관심이 없습니다.

Answer

귀하의 질문은 약간 모호합니다. 질문이 "왜 apt-get update를 실행해야 합니까?"라면, 대답은 apt 업데이트가 시간이 많이 걸리는 프로세스일 수 있다는 것입니다. 패키지를 설치해야 할 때마다 이 작업을 수행하면 시간이 꽤 많이 추가됩니다. 일반적으로 하루에 한 번 캐시를 업데이트하면 충분합니다(이상적으로는 자동화된 방식으로).

"내일 새 패키지를 설치하려는 경우 다시 업데이트할 때까지 서버는 이에 대해 알지 못할 것입니다. 저는 데비안 서버에서만 이 사실을 알아차렸으며 이를 유발하는 어떤 조정도 알지 못합니다."

이 부분에 대해서는 잘 모르겠습니다. 내일 새로운 버전의 unison이 출시된다면 어떻게 알 수 있다는 겁니까? 마찬가지로 apt-get update를 하루에 한 번 이상(예: cron 스크립트를 통해) 실행하면 apt는 새 패키지가 있음을 알게 됩니다. 즉, 새 패키지를 사용할 수 있다는 사실을 자동으로 알려주지 않습니다. 패키지를 업그레이드하면 때때로 사용자가 해결해야 하는 시스템 안정성 문제가 발생할 수 있으므로 이는 타당한 이유가 있습니다.

일반적으로 Debian 기반 시스템에서는 점진적으로 업데이트되는 소프트웨어 버전이 반드시 더 나은 것은 아닙니다. 보안 문제가 있거나 새 버전에 필요한 기능이 없는 한 일반적으로 마이너 버전 업그레이드에는 관심이 없습니다.

Question 2

일반적으로 이는 마지막 업데이트에서 얻은 정확한 버전 정보가 새 버전으로 대체되었기 때문에 데비안 서버에서 더 이상 사용할 수 없음을 의미합니다. 그러나 Squeeze에서는 이런 일이 너무 많이 발생해서는 안 됩니다(보안 업데이트를 고려하더라도). 또 다른 옵션은 /var/lib/apt/lists서버에서 사용할 수 있는 패키지 목록(apt-get update로 가져온 디렉터리도 포함)을 캐시하는 디렉터리를 주기적으로 정리하는 이상한 스크립트(이러한 스크립트는 알지 못합니다)를 사용하는 것입니다 . 불안정하거나 심지어 실험적인 서버(조금 이상해 보이는)를 따르지 않는 한, 이 경우 패키지가 자주 업데이트되므로 캐시 목록이 매우 빠르게 오래된 것이 됩니다. 그래서 제 조언은 apt-get update설치 프로세스를 시작할 때마다 먼저 해당 호출을 수행하도록 근육 기억을 훈련시키는 것입니다 .

Answer

일반적으로 이는 마지막 업데이트에서 얻은 정확한 버전 정보가 새 버전으로 대체되었기 때문에 데비안 서버에서 더 이상 사용할 수 없음을 의미합니다. 그러나 Squeeze에서는 이런 일이 너무 많이 발생해서는 안 됩니다(보안 업데이트를 고려하더라도). 또 다른 옵션은 /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스크립트를 한 줄씩 실행해야만 문제를 발견했습니다. 나는 여기 $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