SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-09-06

Debian unattended-upgrades 작동 안 함 해결 방법

Debian은 기본적으로 unattended-upgrades가 비활성화되어 있습니다. dpkg-reconfigure 명령으로 활성화하는 법과 apt-daily 타이머 확인, Origins-Pattern 설정 등 자동 업데이트가 실행되지 않는 원인과 해결책을 상세히 안내합니다.

새로운 Debian 설치 환경에서 unattended-upgrades가 작동하지 않는 이유

Debian에서 unattended-upgrades 패키지를 설치해도 업데이트가 전혀 실행되지 않는 경우가 있습니다. 이는 패키지 설치와 활성화가 별개의 단계이기 때문입니다. 패키지는 구성 과정에서 debconf 질문을 던지는데, Debian 설치 프로그램은 해당 질문에 대해 false라는 답변을 저장합니다. Ubuntu는 동일한 질문에 반대로 답변하도록 설정되어 있어, 같은 패키지가 Ubuntu에서는 정상 작동하는 것처럼 보이고 Debian에서는 작동하지 않는 것처럼 보입니다.

시스템 어디에서도 이 사실을 알려주지 않습니다. 부팅 시 오류도 없고, 로그인 시 경고도 없으며, 읽을 수 있는 로그 파일도 없습니다. 로그를 기록할 코드 자체가 호출되지 않기 때문입니다. 기능을 켜려면 한 가지 명령어를 실행해야 합니다. 이 가이드의 나머지 부분에서는 명령어를 실행한 후에도 여전히 작동을 방해하는 네 가지 요소인 업데이트 허용 저장소, systemd 타이머의 실제 작동 시점, 실행 실패 확인 방법, 그리고 시스템의 자동 재부팅 허용 여부를 다룹니다.

변경 전 시스템 설정 확인하기

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show은 unattended-upgrades/enable_auto_updates에 저장된 값을 출력합니다. 해당 줄의 시작 부분에 *가 표시되어 있다면, 이는 패키지 기본값이 아닌 다른 설정이 값을 지정했음을 의미합니다. Debian 설치 프로그램으로 구축된 시스템의 경우, 해당 설정은 설치 프로그램이 수행한 것입니다.

cat은 cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory를 출력할 수 있습니다. 이 메시지는 그 자체로 아무런 동작이 없는 이유를 설명합니다. 파일이 없으면 주기적인 키도 없으므로, 예약된 작업이 전혀 없기 때문입니다.

apt-config dump는 가장 중요한 명령어입니다. APT는 /etc/apt/apt.conf.d/에 있는 모든 파일을 파일 이름 순서대로 읽어 병합합니다. 따라서 99local에 설정된 값은 20auto-upgrades의 동일한 값을 덮어씁니다. 개별 파일을 읽으면 해당 파일의 설정만 알 수 있지만, apt-config dump를 사용하면 APT가 실제로 수행할 동작을 확인할 수 있습니다.

작업 실행 여부는 다음 두 가지 키가 결정합니다.

  • APT::Periodic::Update-Package-Lists은 패키지 목록을 새로 고칩니다. 이는 apt update을 수동으로 실행하는 것과 같은 작업입니다.
  • APT::Periodic::Unattended-Upgrade는 업그레이드 자체를 실행합니다.

이 키들의 값은 참이나 거짓이 아닙니다. 일 단위의 간격을 나타냅니다. "1"은 "마지막 실행 후 1일이 지났으면 실행하라"는 의미이며, "7"는 매주, "0"는 실행하지 않음을 의미합니다. APT::Periodic::Unattended-Upgrade "0";은 아무런 경고 없이 영구적으로 아무것도 실행하지 않는 유효한 설정입니다. 만약 덤프 결과에서 해당 키의 값이 0로 나타나거나 키 자체가 없다면, 그것이 바로 작업이 실행되지 않는 원인입니다.

활성화: dpkg-reconfigure 사용 또는 직접 키 작성

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

--priority=low은 여기에서 선택 사항이 아닙니다. 이 질문은 낮은 우선순위로 설정되어 있으므로, 기본 우선순위에서 dpkg-reconfigure는 아무것도 출력하지 않고, 아무것도 변경하지 않으며 0을 반환하고 종료합니다. 이는 마치 명령이 성공적으로 수행된 것처럼 보입니다. 대화 상자에서 예(yes)를 선택하십시오. 그러면 패키지의 postinst 스크립트가 귀하의 답변을 바탕으로 /etc/apt/apt.conf.d/20auto-upgrades을 작성합니다.

스크립트로 빌드하는 머신에는 답변할 대화 상자가 없으므로, 먼저 답변을 설정하십시오:

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

두 개의 키를 직접 작성할 수도 있습니다:

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

이는 즉시 적용되지만 함정을 남깁니다. debconf 답변은 여전히 이전 값을 유지하고 있으므로, 다음 dpkg-reconfigure 실행이나 패키지 재설치 시 debconf의 설정이 파일을 덮어쓰게 되며, 귀하의 수정 사항은 아무런 출력 없이 사라집니다. 두 가지를 모두 설정하거나, debconf를 설정하고 postinst가 파일을 관리하도록 두십시오.

이 점이 다른 계열의 운영체제와 실질적으로 다른 유일한 차이점입니다. 다른 계열에서는 설치 프로그램이 자동으로 해당 패키지를 활성화해주므로, Ubuntu의 unattended-upgrades 설정은 이미 스스로 패치를 수행하는 환경에서 시작하여 튜닝에만 집중할 수 있습니다. 이 지점 아래의 모든 내용은 두 환경 모두에 적용됩니다.

Debian은 실제로 어떤 업데이트를 설치하는가?

타이머를 활성화하는 것과 모든 패키지를 설치하는 것에 동의하는 것은 별개의 문제입니다. 모든 패키지 소스에는 origin, label, suite, codename, site와 같은 릴리스 메타데이터가 포함되어 있습니다. unattended-upgrades는 업그레이드 가능한 각 패키지의 후보 버전을 확인하고, 해당 패키지가 제공되는 소스의 메타데이터를 읽은 뒤, 그 소스가 Unattended-Upgrade::Origins-Pattern의 항목과 일치할 때만 설치를 진행합니다. 설계상 일치하는 항목이 없으면 아무런 알림 없이 업그레이드하지 않습니다.

패턴을 출력한 다음, 해당 패턴이 대조되는 메타데이터를 출력하십시오:

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H은 각 줄에 파일 이름을 유지하므로, 각 메타데이터 블록이 어떤 소스에 속하는지 확인할 수 있습니다. 해당 필드 값들은 패턴의 우변에 해당합니다. 패턴 내부의 ${distro_codename}는 런타임에 현재 사용 중인 릴리스의 코드네임으로 치환되므로, 릴리스 업그레이드 후에도 하나의 파일로 계속 작동합니다.

"보안 수정 사항만 설치되는가, 아니면 포인트 릴리스 업데이트도 포함되는가"에 대한 답은 다른 곳이 아닌 바로 그 메타데이터 옆에 적혀 있으므로, 직접 작성한 패턴을 메타데이터와 함께 읽어보십시오:

  • label=Debian-Security를 지정하는 패턴은 보안 아카이브와 일치합니다. 이곳이 Debian 보안 권고가 게시되는 곳입니다.
  • -updates 스위트를 지정하는 패턴은 stable-updates와 일치하며, 여기에는 시간대 데이터와 같이 Debian이 포인트 릴리스 사이에 배포하는 변경 사항이 포함됩니다.
  • 일반 릴리스 스위트를 지정하는 패턴은 포인트 릴리스 변경 사항이 게시될 때마다 이를 가져오며, 이는 사용자 입장에서 더 많은 변경과 테스트 작업을 의미합니다.
  • 직접 추가한 저장소는 패턴을 작성하기 전까지는 아무것도 일치하지 않습니다.

마지막 항목은 사용자들을 놀라게 하는 부분입니다. 타사 저장소는 고유한 origin과 label을 가지고 있으므로, unattended-upgrades는 후보 버전을 확인하고 소스가 아무것도 일치하지 않는 것을 확인한 뒤 다음으로 넘어갑니다. 타사 저장소를 위한 패턴을 추가하는 것은 신중하게 결정해야 합니다. 벤더 저장소는 동일한 스위트 내에서 새로운 메이저 버전을 배포할 수 있으며, 이 경우 한밤중에 해당 소프트웨어의 메이저 업그레이드가 자동으로 수행되는 것에 동의하게 되기 때문입니다.

또한 unattended-upgrades는 Debian 릴리스 간의 이동을 수행하지 않습니다. 현재 사용 중인 릴리스 내에서만 패키지를 업그레이드합니다. 한 stable 릴리스에서 다음 릴리스로 넘어가는 작업은 사용자가 직접 일정을 잡고 수행해야 하는 수동 작업으로 남습니다.

목록을 변경할 때는 APT 목록이 추가(append) 방식으로 동작한다는 점을 기억하십시오. 다른 파일에 두 번째 Origins-Pattern 블록을 작성하면 기존 목록을 대체하는 것이 아니라 추가되므로, 교체하려는 의도라면 먼저 기존 내용을 비워야 합니다:

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

로컬 변경 사항은 기본 제공 파일보다 뒤에 정렬되는 새 파일(예: /etc/apt/apt.conf.d/52unattended-upgrades-local)에 작성하십시오. 50unattended-upgrades는 conffile이므로, 이를 직접 수정하면 향후 패키지 업그레이드 시마다 사용자의 버전과 충돌이 발생하여 처리 방법을 묻게 됩니다. 별도의 파일을 사용하면 충돌이 발생하지 않습니다.

이 작업을 수행하는 동안 두 가지 키를 더 출력해 볼 가치가 있습니다. Unattended-Upgrade::Allowed-Origins은 동일한 개념의 구형 형식으로 origin:archive 쌍으로 작성되며, 여전히 읽히기 때문에 튜토리얼에서 복사한 설정은 종종 두 목록을 모두 포함하게 되어 어떤 것이 일치했는지 명확하지 않게 됩니다. Unattended-Upgrade::Package-Blacklist는 패키지 이름과 대조되는 정규 표현식을 담고 있으며, 여기서 느슨한 표현식을 사용하면 의도한 것보다 훨씬 많은 패키지가 차단될 수 있습니다. 아래의 드라이 런(dry run)은 실제로 적용된 내용을 출력합니다.

예상한 시간에 아무것도 실행되지 않는 이유는 무엇입니까?

두 개의 systemd 타이머가 이 작업을 수행하며, 각각 다른 역할을 합니다. apt-daily.timer은 apt-daily.service를 시작하여 패키지 목록을 새로 고치고 다운로드합니다. apt-daily-upgrade.timer는 apt-daily-upgrade.service을 시작하며, 이 서비스가 unattended-upgrade을 호출합니다. 두 타이머 모두 서로 다른 인자를 사용하여 /usr/lib/apt/apt.systemd.daily을 실행합니다. 두 번째 타이머가 비활성화되거나 마스킹(masked)된 상태라면, 두 주기적 키가 1를 읽을 수는 있어도 실제로 설치되는 항목은 없습니다.

systemctl list-timers 'apt-daily*' --all
systemctl is-enabled apt-daily.timer apt-daily-upgrade.timer
systemctl cat apt-daily-upgrade.timer

list-timers은 각 유닛에 대한 NEXT, LEFT, LAST 및 PASSED 정보를 제공합니다. NEXT가 없는 타이머는 실행되지 않습니다. is-enabled 출력에 masked이 표시된다면 누군가 강제로 해당 타이머를 끈 것이며, apt.conf.d에 무엇을 작성하더라도 이 상태는 바뀌지 않습니다.

이제 systemctl cat이 출력한 [Timer] 섹션을 읽어 보십시오. OnCalendar은 타이머가 실행될 수 있는 가장 빠른 시간입니다. RandomizedDelaySec는 그 시점 이후에 임의의 대기 시간을 추가하므로, 여러 대의 Debian 장비가 동시에 같은 미러 서버에 접속하지 않게 됩니다. 이것이 NEXT 열에 표시된 시간이 OnCalendar와 일치하지 않는 이유이며, 어제 실행된 작업이 오늘과 다른 분에 수행된 이유입니다. 이는 설계된 대로 작동하는 것입니다. Persistent=true는 예약된 시간에 전원이 꺼져 있던 장비가 부팅된 직후 작업을 수행하여 해당 날짜의 작업을 건너뛰지 않도록 합니다.

실행 시간대를 변경하려면 유닛을 직접 수정하지 말고 오버라이드(override)하십시오:

sudo systemctl edit apt-daily-upgrade.timer
[Timer]
OnCalendar=
OnCalendar=03:30
RandomizedDelaySec=30m

빈 OnCalendar= 줄은 반드시 필요합니다. 리스트 형태의 유닛 설정은 누적되기 때문입니다. 이 줄을 생략하면 기본 제공된 스케줄이 유지된 상태에서 새로운 스케줄이 추가됩니다. systemctl edit은 systemd 설정을 다시 불러오므로, systemctl list-timers 'apt-daily*'로 결과를 확인하고 새로운 NEXT를 살펴보십시오.

이 모든 것을 테스트하기 위해 타이머가 돌아올 때까지 기다릴 필요는 없습니다:

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

/etc/cron.daily 내부를 살펴보는 사람들이 혼란스러워하는 점이 하나 있습니다. APT는 여전히 systemd를 사용하지 않는 시스템을 위해 /etc/cron.daily/apt-compat을 제공합니다. cat를 사용하여 이 파일을 읽어 보십시오. systemd 시스템에서는 이 스크립트가 즉시 종료되므로 작업이 중복 수행되지 않습니다.

작동 확인: unattended-upgrade --dry-run --debug

sudo unattended-upgrade --dry-run --debug

바이너리는 단수형이고 패키지 이름은 복수형입니다. 여기서 unattended-upgrades을 입력하면 command not found가 출력되는데, 많은 사용자가 이를 패키지가 누락되었다는 증거로 오해합니다.

이 명령어 하나로 "왜 해당 패키지를 건너뛰었는가"에 대한 거의 모든 질문에 답할 수 있습니다. 명령어 자체가 판단 근거를 출력하기 때문입니다. 출력 상단 근처에는 사용자의 패턴으로부터 계산된 origin이 표시됩니다.

Allowed origins are: ...

그다음에는 후보 패키지마다 한 줄씩, 설치할 버전의 origin 기록이 표시됩니다.

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

이어서 작업 대상 목록이 표시되거나, 작업할 내용이 없는 서버라면 다음과 같이 출력됩니다.

No packages found that can be upgraded unattended and no pending auto-removals

첫 번째와 두 번째 출력 내용을 함께 보면 진단이 바로 가능합니다. 업그레이드될 것으로 예상했던 패키지의 Checking: 줄을 찾으십시오. 그 위에 출력된 허용된 origin들과 해당 패키지의 origin 기록을 필드별로 비교하십시오. 일치하지 않는 필드 하나(주로 label 또는 archive)가 패키지를 건너뛴 유일한 이유입니다.

--dry-run은 패키지를 메모리에만 기록하고 아무것도 설치하지 않으므로, 원하는 만큼 자주 실행해도 됩니다. 다만 /var/log/unattended-upgrades/unattended-upgrades.log에는 계속 기록이 추가됩니다.

origin이 일치하는데도 패키지가 보류된다면 다음 사항들을 확인하십시오.

  • apt-mark showhold은 사용자가 직접 또는 도구를 통해 고정한(pin) 패키지 목록을 보여줍니다. unattended-upgrades는 고정된 패키지를 변경하지 않습니다.
  • 업그레이드를 위해 다른 패키지를 삭제하거나 추가해야 하는 경우입니다. 관련 키 설정에서 허용하지 않는 한 unattended-upgrades는 이를 피하므로, 안전 규칙을 적용하지 않고 동일한 판단을 보여주는 sudo apt-get -s upgrade과 비교해 보십시오.
  • 중단된 작업으로 인해 dpkg가 반쯤 설정된 상태일 수 있습니다. sudo dpkg --configure -a로 해결한 뒤 다시 확인하십시오.
  • /var에 여유 공간이 없어 다운로드나 압축 해제가 불가능한 경우입니다. df -h /var로 확인하십시오.
  • /boot가 오래된 커널로 가득 차 있어 다음 커널 업그레이드가 실패하는 경우입니다. df -h /boot을 확인하고, apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages을 출력하여 정리 기능이 켜져 있는지 확인하십시오.

타이머가 작동 중일 때 수동으로 apt을 실행하면 Could not get lock /var/lib/dpkg/lock-frontend가 출력됩니다. 이 메시지는 unattended-upgrades가 정상적으로 작업을 수행 중임을 의미합니다. 작업이 끝날 때까지 기다리십시오.

실행 실패 여부를 확인하는 방법

별도의 설정을 하지 않아도 로그는 항상 생성되므로 로그부터 확인하십시오.

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

첫 번째 파일은 결정 로그(decision log)로, 무엇을 확인했고 무엇을 선택했으며 무엇을 설치했는지 기록합니다. 두 번째 파일은 원시 dpkg 출력 결과를 담고 있으며, postinst 스크립트가 실패한 패키지의 원인이 여기에 나타납니다. 시스템 종료 중에 업그레이드가 실행되면 별도의 종료 로그가 생성됩니다.

메일은 일반적인 보고 경로입니다.

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport은 always, on-change, only-on-error 설정을 지원합니다. only-on-error는 원칙적인 선택처럼 보이지만, 아무도 로그인하지 않는 서버에서는 대개 잘못된 선택입니다. 업그레이드가 완전히 중단된 기계는 오류 메시지도 보내지 않기 때문입니다. 이 경우 정상적인 서버와 죽은 서버 모두 침묵 상태가 되어 구분할 수 없게 됩니다. on-change는 무언가 설치될 때마다 메일을 보내므로, 이 메일은 타이머가 여전히 작동 중이라는 증거로도 활용할 수 있습니다.

메일은 기계가 메일을 보낼 수 있는 환경일 때만 외부로 나갑니다. unattended-upgrades는 메시지를 로컬 메일 시스템으로 전달하므로, postfix와 같은 MTA(메일 전송 에이전트)나 msmtp와 같은 sendmail 호환 릴레이 클라이언트가 필요합니다. command -v sendmail 및 command -v mail 명령으로 확인하십시오. 둘 다 설치되어 있지 않으면 보고서는 어디로도 전송되지 않으며, 업그레이드는 성공한 것처럼 보이고 전체 실패 과정은 보이지 않게 됩니다. 또한 새로운 VPS IP 주소는 발신 평판이 없으므로, 공용 메일함으로 직접 보낸 메일은 스팸으로 분류되는 경우가 많다는 점을 기억하십시오. 이를 위해 직접 서버를 운영하는 것보다 이미 사용 중인 메일 제공업체를 통해 릴레이하는 것이 더 안정적입니다.

메일을 전혀 사용하고 싶지 않다면, 보유 중인 모니터링 도구로 로그 타임스탬프를 감시하십시오.

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

일주일 동안 타임스탬프가 변하지 않았다면 설정 내용과 관계없이 타이머가 멈춘 것입니다. 해당 확인 작업은 정기적인 Linux 서버 유지보수 점검 항목에 포함해야 합니다.

서버가 자동으로 재부팅되어야 합니까?

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot 설정이 true로 되어 있으면, unattended-upgrades는 확인 절차 없이 재부팅을 수행합니다. 단, 작업이 완료된 후 /var/run/reboot-required 파일이 존재할 때만 재부팅합니다. 이 마커 파일은 unattended-upgrades가 직접 생성하지 않습니다. 다른 패키지가 이 파일을 생성해야 하며, Debian에서는 일반적으로 needrestart이 이 역할을 수행합니다. 이 파일이 항상 존재한다고 가정하지 마십시오. 다음 커널 업그레이드 후에 확인하십시오.

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

만약 해당 파일이 시스템에 나타나지 않는다면 Automatic-Reboot "true"는 절대 실행되지 않습니다. 이 경우 커널 업데이트를 위해 재부팅이 이루어지고 있다고 몇 달 동안 오해하면서, 실제로는 이전 커널을 계속 사용하게 될 수 있습니다. 가장 최근에 설치된 linux-image 패키지를 기준으로 uname -r을 실행하면 이를 확실히 확인할 수 있습니다.

Automatic-Reboot-Time는 즉시 재부팅하는 대신 지정된 시간에 재부팅을 예약합니다. Automatic-Reboot-WithUsers이 false로 설정되면 사용자가 로그인 중일 때 재부팅을 건너뜁니다. 항상 세션이 열려 있는 서버라면 재부팅이 전혀 이루어지지 않을 수 있습니다.

재부팅 여부보다 중요한 것은 재부팅 이후의 상황입니다. 수동으로 시작한 서비스는 재부팅 후 자동으로 다시 시작되지 않습니다. 부팅 시 암호가 필요한 암호화 볼륨은 자동으로 마운트되지 않습니다. 서로 의존하는 두 대의 서버는 잘못된 순서로 부팅될 수 있습니다. 02:00에 1분 정도 서비스가 중단되어도 무방한 상태 비저장(stateless) 웹 서버라면 자동 재부팅을 활성화하십시오. 사람이 직접 개입해야 하는 환경이라면 자동 재부팅을 끄고, 마커 파일을 감시하여 관리자가 직접 재부팅 시점을 결정하도록 하십시오. 그 중간 단계에는 needrestart이 있습니다. 이 도구는 업그레이드된 라이브러리를 참조 중인 서비스만 다시 시작하므로 커널을 제외한 모든 변경 사항을 처리합니다. 기본 모드에서는 재시작 전 사용자에게 확인을 요청하므로, 무인 실행에 의존하기 전에 /etc/needrestart/needrestart.conf를 읽어보시기 바랍니다.

테스팅(testing)과 언스테이블(unstable)에서도 동일하게 작동합니까?

위의 모든 내용은 데비안 스테이블(Debian stable)을 기준으로 설명되었습니다. 스테이블 버전은 보안 수정 사항이 별도의 아카이브를 통해 고유한 레이블로 제공됩니다. 이러한 구조 덕분에 "보안 업데이트만"이라는 설정을 명시적으로 적용할 수 있습니다. 다른 스위트(suite)는 구성 방식이 다르므로, 스테이블 서버에서 복사한 설정을 그대로 사용하면 작성자의 의도와 다르게 동작할 수 있습니다. 또한, 변경이 잦은 스위트에서 자동 업그레이드를 수행하면 예고 없이 메이저 버전이 변경될 수 있습니다. 이는 스테이블 버전과는 다른 차원의 문제입니다. 이러한 선택을 고려 중이라면 서버에서 데비안 스테이블, 테스팅, 언스테이블 운영하기를 통해 각 버전이 보장하는 내용을 확인하십시오. 레드햇(Red Hat) 계열에서는 동일한 작업을 수행하기 위해 다른 도구와 용어를 사용하며, Rocky Linux와 AlmaLinux에서의 dnf-automatic에서 고유한 타이머와 설정 파일을 통한 방법을 다룹니다.

자동 업그레이드는 수정 사항이 발표된 시점과 실제 설치되는 시점 사이의 간격을 줄여줍니다. 하지만 자동 업그레이드만으로는 여전히 노출된 취약점을 모두 파악할 수 없으므로, 서버의 알려진 CVE 점검과 병행해야 합니다. CVE는 Common Vulnerabilities and Exposures의 약자로, 수정 사항을 추적하는 데 사용되는 공개 식별자입니다.

5분 점검

  1. apt-config dump APT::Periodic은(는) 0이 아닌 값을 가진 두 키를 모두 출력합니다.
  2. systemctl list-timers 'apt-daily*'은(는) 두 타이머 모두에 대해 NEXT 시간을 출력합니다.
  3. sudo unattended-upgrade --dry-run --debug은(는) 사용 중인 코드네임의 보안 아카이브를 포함하는 허용된 오리진을 출력합니다.
  4. sudo systemctl start apt-daily-upgrade.service이(가) 완료되고 /var/log/unattended-upgrades/unattended-upgrades.log의 타임스탬프가 변경됩니다.
  5. 일주일 후, 동일한 로그에 설치된 패키지 이름이 기록됩니다.

처음 네 단계를 통과했다면 시스템이 구성된 것입니다. 다섯 번째 단계까지 통과했다면 정상적으로 작동하는 것입니다.

FAQ

Debian은 왜 unattended-upgrades를 설치하고도 비활성화 상태로 두나요?

해당 패키지는 debconf 질문인 unattended-upgrades/enable_auto_updates을 던지고 그 답변을 바탕으로 /etc/apt/apt.conf.d/20auto-upgrades을 작성합니다. Debian 설치 프로그램은 해당 질문에 대한 false을 저장해 두기 때문에, 패키지가 작업 단위나 의존성으로 설치될 때는 아무것도 하지 않도록 설정됩니다. sudo debconf-show unattended-upgrades를 실행하여 저장된 답변을 확인하고, sudo dpkg-reconfigure --priority=low unattended-upgrades을 실행하여 이를 변경하십시오. 낮은 우선순위가 중요한 이유는 기본 우선순위에서는 명령이 질문을 표시하지 않고 즉시 종료되기 때문입니다.

타이머를 기다리지 않고 unattended-upgrades를 테스트하려면 어떻게 하나요?

sudo unattended-upgrade --dry-run --debug을 실행하십시오. 이 명령은 허용할 원본을 출력하고, 업그레이드 가능한 각 패키지에 대해 해당 패키지의 원본 기록이 포함된 Checking: 라인을 보여주며, 실제 설치는 하지 않은 채 설치할 패키지 목록을 나열합니다. 실제 동작 과정을 확인하려면 sudo systemctl start apt-daily-upgrade.service을 실행한 뒤 journalctl -u apt-daily-upgrade.service --since -1h와 /var/log/unattended-upgrades/unattended-upgrades.log를 함께 읽어보십시오.

unattended-upgrades는 보안 수정 사항 외에 일반 업데이트도 설치하나요?

패턴에 명시된 경우에만 설치합니다. 패키지 업그레이드는 해당 패키지의 출처가 Unattended-Upgrade::Origins-Pattern의 항목과 일치할 때 수행되며, 보안 아카이브, stable-updates 제품군, 그리고 사용자가 직접 추가한 저장소는 각각 별도의 항목으로 취급됩니다. 자신의 시스템에서 apt-config dump Unattended-Upgrade::Origins-Pattern을 출력한 뒤 grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release과 비교해 보십시오. 또한 이 도구는 Debian 릴리스 간의 업그레이드를 수행하지 않습니다.

왜 업그레이드가 타이머에 설정된 시간에 실행되지 않나요?

apt-daily-upgrade.timer는 OnCalendar 위에 RandomizedDelaySec을 설정하므로, systemd는 지정된 시간에 정확히 실행하는 대신 해당 시간 범위 내의 무작위 시점을 선택합니다. 이는 동일한 미러를 사용하는 모든 Debian 시스템에 부하를 분산하기 위함입니다. systemctl list-timers 'apt-daily*'를 실행하면 실제로 선택된 실행 시점을 확인할 수 있습니다. 시간 범위를 변경하려면 sudo systemctl edit apt-daily-upgrade.timer을 실행하고 빈 OnCalendar= 라인을 입력한 뒤 원하는 값을 설정하십시오.

보안 업데이트를 위해 자동 재부팅을 켜야 할까요?

예기치 않은 재시작이 안전한 환경에서만 켜야 합니다. Unattended-Upgrade::Automatic-Reboot "true"는 실행 후 /var/run/reboot-required이 존재하면 확인 절차 없이 재부팅을 수행합니다. 이 마커 파일은 unattended-upgrades 자체가 아니라 보통 needrestart과 같은 다른 패키지에 의해 생성됩니다. 설정을 신뢰하기 전에 커널 업그레이드 후 해당 파일이 시스템에 생성되는지 먼저 확인하십시오. 부팅 시 암호가 필요하거나 수동으로 시작한 서비스가 실행 중인 시스템이라면, 이 설정을 false로 두고 마커 파일을 감시하여 사람이 직접 재부팅 시점을 결정하도록 하십시오.

#debian#unattended-upgrades#apt#systemd#security-updates