Rocky Linux 및 AlmaLinux dnf-automatic 설정 방법

Rocky Linux 및 AlmaLinux에서 dnf-automatic의 역할

dnf-automatic은 Rocky Linux 및 AlmaLinux에서 보안 업데이트를 자동으로 수행하는 도구입니다. 이 작은 프로그램은 systemd 타이머에 의해 실행되며, /etc/dnf/automatic.conf 파일을 읽어 해당 설정이 허용하는 작업을 수행합니다. 설치는 단 하나의 명령어로 완료됩니다. 이 가이드의 나머지 부분에서는 시스템을 보호할지, 아니면 아무런 작업도 하지 않을지를 결정하는 설정에 대해 다룹니다.

Debian이나 Ubuntu 환경에서 전환했다면, 이는 Ubuntu VPS에서 unattended-upgrades가 수행하는 작업과 동일합니다. 다른 모든 차이점보다 중요한 한 가지는 패키지 관리자가 "보안(security)"이라는 단어를 어떻게 정의하느냐입니다. Ubuntu에서 이는 별도의 아카이브 포켓(archive pocket)을 의미합니다. 반면 RHEL 계열에서는 게시된 권고 사항(advisory)에 첨부된 메타데이터를 의미하며, 이 메타데이터는 누락되거나 최신 상태가 아닐 수 있습니다. 권고 데이터가 없는 저장소를 dnf-automatic이 참조하도록 설정하면, 성공했다고 보고하면서도 실제로는 아무것도 설치하지 않습니다.

이 가이드는 2026년 8월 기준으로 DNF 4(RHEL 계열의 패키지 관리자)를 사용하는 Rocky Linux 9 및 AlmaLinux 9를 대상으로 작성되었습니다. 버전 10 릴리스에서는 DNF5로 전환되면서 명칭이 변경되었으므로, 해당 내용은 마지막 부분의 별도 섹션에서 다룹니다. 아래의 모든 명령어는 사용자의 서버에서 직접 실행할 수 있으며, 그 옆에는 예상되는 출력 결과가 기재되어 있습니다.

dnf-automatic 설치 및 기본 설정 파일 확인

자동 업데이트 활성화는 새 VPS 설정의 첫 10분 과정 중, 비루트(non-root) 사용자와 방화벽 설정을 마친 직후에 수행해야 합니다.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled은 패키지를 설치해도 아무것도 시작하지 않기 때문에, 새로 설치한 환경에서는 disabled를 출력합니다. 이것이 "dnf-automatic이 설치된" 서버에서 업데이트가 단 한 번도 적용되지 않는 가장 흔한 이유입니다.

DNF 버전은 특정 옵션 설정에 영향을 미칩니다. reboot 설정은 DNF 4.15 버전에서 업스트림으로 도입되었으며, Red Hat은 2023년 11월 RHBA-2023:6645 권고를 통해 이를 dnf-4.14.0-6.el9로 백포트했습니다. Rocky 9와 AlmaLinux 9는 해당 패키지를 다시 빌드하므로, 최신 상태의 서버는 이 기능을 포함하고 있으나 2023년 이후 업데이트하지 않은 서버는 포함하고 있지 않습니다.

설정 파일은 /etc/dnf/automatic.conf입니다. 제공된 기본 파일에는 현재 빌드에서 인식하는 모든 옵션과 그 기본값이 주석 처리되어 나열되어 있습니다. 이 파일은 사용 중인 버전에 대한 정확한 정보를 담고 있으므로, 수정하기 전에 반드시 한 번 읽어보시기 바랍니다.

동작을 결정하는 두 가지 스위치

download_updates와 apply_updates는 [commands] 섹션에서 동작 방식을 결정합니다. EL9(Rocky 9와 AlmaLinux 9의 공통 기반인 enterprise Linux 9)에서는 기본적으로 두 항목 모두 no으로 설정되어 있으므로, 설정을 변경하지 않고 dnf-automatic을 활성화하면 사용 가능한 업데이트 정보만 알림으로 받게 됩니다.

• 두 항목 모두 no: dnf-automatic은 사용 가능한 업데이트를 보고할 뿐 서버의 상태를 변경하지 않습니다.
• download_updates = yes 및 apply_updates = no: 패키지가 DNF 캐시로 다운로드됩니다. 이후 설치 과정은 네트워크 연결 없이 빠르게 진행되지만, 당장 시스템이 변경되지는 않습니다.
• 두 항목 모두 yes 및 upgrade_type = default: 보안 업데이트 여부와 관계없이 사용 가능한 모든 업데이트가 설치됩니다.
• 두 항목 모두 yes 및 upgrade_type = security: 보안 권고(security advisory)에 명시된 패키지만 설치됩니다.

외부에 노출된 VPS를 위한 합리적인 시작 설정은 다음과 같습니다.

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout는 부팅 직후의 서버에서 네트워크 연결을 기다릴 최대 시간(초)을 의미합니다. random_sleep는 여러 대의 서버에 부하를 분산하기 위한 구식 방식이며, 현재는 타이머가 해당 역할을 수행합니다. systemctl cat dnf-automatic.service을 실행하면 배포된 서비스가 실제로 사용하는 플래그를 정확히 확인할 수 있습니다.

06:00까지 기다리지 않고 설정 파일이 의도대로 작동하는지 확인하려면 다음 명령을 사용하십시오.

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

저널(journal)을 통해 실행 과정에서 고려된 사항과 수행된 작업을 확인할 수 있습니다. 또한 명령줄에서 특정 동작을 강제로 지정하여 실행할 수도 있으며, 이 경우 해당 실행에 한해 설정 파일의 내용이 무시됩니다.

sudo dnf-automatic --downloadupdates --no-installupdates

Rocky와 Alma에서 upgrade_type = security가 실제로 의미하는 것

DNF는 버전 번호를 비교하여 업데이트가 보안 업데이트인지 판단하지 않습니다. DNF는 updateinfo.xml이라는 파일에 게시된 errata 메타데이터를 읽으며, 각 권고(advisory)에는 해당 문제를 해결하는 패키지 목록이 나열되어 있습니다. AlmaLinux는 이를 ALSA 권고로, Rocky는 RLSA로 게시합니다. upgrade_type = security은 해당 메타데이터에서 필터를 생성하여 일치하는 패키지만 업그레이드합니다.

여기에는 두 가지 결과가 따르며, 둘 다 사용자들을 당황하게 만듭니다.

첫째, 메타데이터가 없으면 업데이트도 없습니다. 저장소에 updateinfo.xml가 포함되어 있지 않으면 필터는 아무것도 일치시키지 못하며, 작업은 저널에 다음 줄을 남기고 종료됩니다.

No security updates needed, but 3 updates available

시스템은 패치되지 않았지만, 실패를 보고하는 항목도 없습니다. 직접 확인하려면 다음 명령을 사용하십시오.

dnf updateinfo list --security
dnf check-update

dnf check-update은 패키지를 나열하는데 dnf updateinfo list --security은 아무것도 출력하지 않는다면, 보류 중인 업데이트 중 권고 사항이 포함된 것이 없거나 저장소에 읽을 권고 데이터가 없는 것입니다. Rocky와 AlmaLinux는 모두 이를 게시하므로, 이 두 배포판에서 빈 목록이 출력된다면 대개는 정상적인 상황입니다. CentOS Stream은 이를 전혀 게시하지 않습니다.

둘째, 보안 모드는 최소한의 변경만을 의미하지 않습니다. dnf-automatic은 보안 필터를 추가한 뒤 일반적인 업그레이드 경로를 실행합니다. 따라서 권고 사항에 명시된 패키지는 저장소 내 최신 버전으로 이동하며 의존성 패키지들도 함께 업데이트됩니다. 권고 사항을 해결하는 가장 초기 버전으로만 이동하는 더 작은 단위의 업데이트는 수동으로 dnf upgrade-minimal --security를 실행해야 가능합니다. dnf-automatic에는 이를 위한 설정이 없습니다.

Rocky에는 한 가지 주의 사항이 더 있습니다. Rocky는 Red Hat 데이터를 자체 파이프라인을 통해 처리하여 errata를 생성하는데, 이 파이프라인이 지연되는 경우가 있습니다. 2025년 9월, 사용자들은 Rocky 9 BaseOS updateinfo.xml이 2024년 12월 이후로 업데이트되지 않았다고 보고했으며, 이로 인해 --security에서 최근 권고 사항이 누락되었습니다. Rocky 운영진은 이를 알려진 문제로 확인했습니다. upgrade_type = security에 의존하고 있다면, 가끔씩 권고 목록을 최근 RLSA 공지 사항과 대조해 보십시오. 변경 제어보다 보안 적용 범위가 더 중요한 환경이라면, 원하는 일정에 맞춰 upgrade_type = default을 실행하는 것이 더 안전한 설정입니다.

실제로 작업을 실행하는 systemd 타이머

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers 명령은 약 하루 뒤의 NEXT 시간을 포함한 한 행을 출력해야 합니다. 표가 비어 있다면 타이머가 활성화되지 않은 것이며, 따라서 아무 작업도 실행되지 않습니다.

기본 제공되는 타이머는 *-*-* 6:00에 RandomizedDelaySec=60m 및 Persistent=true와 함께 실행됩니다. 무작위 지연 시간(random delay)은 모든 서버가 동일한 초에 미러 서버로 접속하지 않도록 전체 서버군의 부하를 1시간 동안 분산합니다. Persistent=true 설정은 06:00에 전원이 꺼져 있던 서버가 부팅된 직후 누락된 작업을 실행하도록 하여, 해당 일의 작업을 건너뛰지 않게 합니다.

일정 변경은 드롭인(drop-in) 파일을 사용하십시오. 기본 제공되는 유닛 파일을 직접 수정하지 마십시오. 패키지 업그레이드 시 /usr/lib/systemd/system 아래의 파일들이 교체되기 때문입니다.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

비어 있는 OnCalendar= 행은 필수입니다. OnCalendar 설정은 누적되므로, 해당 초기화 구문이 없으면 기존 06:00 항목이 유지된 상태에서 새로운 항목이 추가되어 작업이 하루에 두 번 실행됩니다. systemctl list-timers dnf-automatic.timer 명령으로 결과를 확인하고 NEXT 열을 읽어 보십시오. 동일한 드롭인 규칙이 다른 모든 예약 작업에도 적용되며, 자세한 내용은 systemd 서비스 및 타이머 유닛 작성에서 다룹니다.

이제 주의할 점입니다. 해당 패키지는 dnf-automatic-notifyonly.timer, dnf-automatic-download.timer, dnf-automatic-install.timer라는 세 가지 타이머를 추가로 제공합니다. 각 타이머는 명령줄 플래그와 함께 동일한 프로그램을 시작하며, 이 플래그들은 설정 파일의 download_updates 및 apply_updates 값을 덮어씁니다. dnf-automatic.timer과 함께 이들 중 하나를 활성화하면 작업이 서로 다른 동작으로 두 번 실행되는데, 이는 마치 설정 파일이 무시되는 것처럼 보일 수 있습니다. 타이머 하나를 활성화한 뒤 다음을 확인하십시오.

systemctl list-unit-files 'dnf-automatic*'

설치 시점은 어떻게 확인합니까?

emit_via의 [emitters] 섹션에서 보고 기능을 제어합니다. systemd 환경에서 stdio 이미터는 저널에 기록을 남기며, 별도의 추가 설치가 필요하지 않아 가장 신뢰할 수 있는 옵션입니다.

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

motd 이미터는 보고서를 /etc/motd에 기록하며 해당 파일의 내용을 덮어씁니다. 로그인 배너를 해당 파일에 유지하고 있다면 이 이미터는 사용하지 마십시오.

email 이미터는 email_host의 email_port 포트로 SMTP(Simple Mail Transfer Protocol) 연결을 시도하며, 기본값은 각각 localhost와 25입니다. 새로 생성된 VPS에는 해당 포트에서 대기 중인 서비스가 없으므로 연결이 거부되고 메일이 발송되지 않습니다. 이 기능을 사용하기 전에 ss -lnt | grep ':25'을 실행하고, 출력이 비어 있다면 릴레이 전용 Postfix를 설정하십시오. 메일 발송이 정상적으로 작동하면 메일 제목은 Updates applied on 'web01'.로 표시되며, 이름은 system_name에서 가져옵니다.

그 외의 경우, command 이미터를 사용하면 보고서가 표준 입력(standard input)을 통해 사용자가 지정한 프로그램으로 전달됩니다.

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages의 기본값은 no이며, 이는 실행에 실패할 경우 아무런 보고도 하지 않음을 의미합니다. 이 설정을 활성화하십시오. 성공한 작업만 알리는 패치 시스템은 침묵을 정상 상태로 오인하게 만들어, 아예 없는 것보다 더 위험합니다.

dnf-automatic은 서비스를 재시작하지 않습니다

패키지를 설치하면 디스크의 파일이 교체됩니다. 이미 실행 중인 프로세스는 이전 코드를 메모리에 유지하므로, 지난달에 시작된 데몬은 패치된 라이브러리를 사용하지 않습니다. 설치된 상태와 실제 적용된 상태 사이의 이러한 간극 때문에, 자동 패치에는 설치 정책뿐만 아니라 재시작 정책이 필요합니다.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s는 서비스 시작 이후 파일이 변경된 systemd 서비스를 나열합니다. -r은 하나의 질문에 답하며, 다음 두 블록 중 하나를 출력합니다.

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r은 정밀한 분석 도구가 아닙니다. 이 도구는 kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl와 같이 고정된 패키지 목록을 확인합니다. 이 중 하나라도 마지막 부팅 이후에 설치되었다면 첫 번째 답변이 출력됩니다. 서버 내 다른 요소도 재부팅이 필요하다면 /etc/dnf/plugins/needs-restarting.d/ 아래에 .conf로 끝나는 파일을 생성하여 패키지 이름을 추가하십시오.

스크립트 작성 시 주의할 점이 있습니다. dnf needs-restarting -r는 재부팅이 필요할 때와 명령 자체가 실패했을 때 모두 0이 아닌 값을 반환하므로, 종료 상태 코드만으로는 두 상황을 구분할 수 없습니다. 출력된 텍스트를 확인하십시오.

서비스를 재시작하는 것이 더 작은 조치이며 보통 올바른 방법입니다. 잘못된 설정으로 인해 접속이 차단되는 것을 방지하려면, 이미 열려 있는 두 번째 SSH 세션에서 SSH 데몬을 재시작하십시오. 새로운 커널은 실행 중인 커널을 즉석에서 교체할 수 없으므로 재부팅만이 유일한 해결책인 경우입니다.

서버가 스스로 재부팅되어야 합니까?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never가 기본값입니다. when-changed은 업데이트가 적용된 후 항상 재부팅을 수행합니다. when-needed은 needs-restarting -r 뒤의 검사 결과 핵심 패키지가 교체되었다고 판단될 때만 재부팅합니다. 이는 대부분의 단일 서버 운영자가 원하는 방식이며, 직접 선택한 타이머 윈도우와 함께 사용합니다. 기본값인 reboot_command는 shutdown을 통해 로그인한 사용자에게 5분간 경고를 보내며, 이 시간은 더 길게 설정할 수 있습니다.

이 기능을 활성화하기 전에 두 가지를 먼저 해결해야 합니다. 의존하는 모든 서비스는 부팅 시 자동으로 시작되도록 설정되어 있어야 합니다. 이는 수동으로 시작한 Docker Compose 스택에서 흔히 발생하는 문제입니다. 또한, 제공업체로부터 콘솔이나 복구 모드 접근 권한을 확보해야 합니다. 부팅되지 않는 커널은 SSH를 통해 수정할 수 없기 때문입니다. 이 중 하나라도 준비되지 않았다면 reboot = never을 유지하고, 저널을 확인한 뒤 직접 재부팅하십시오.

Rocky, AlmaLinux 및 CentOS Stream: 차이점

Rocky 9와 AlmaLinux 9에서는 위에서 설명한 모든 내용이 설정 경로와 유닛 이름을 포함하여 동일하게 적용됩니다. 두 배포판 모두 에러타(errata)를 게시하므로 upgrade_type = security를 통해 데이터를 필터링할 수 있습니다.

CentOS Stream은 예외이며, 다루기가 까다롭습니다. Stream 저장소는 updateinfo.xml 정보를 포함하지 않으므로 보안 필터가 일치하는 항목을 찾을 수 없으며, 실행할 때마다 No security updates needed를 보고합니다. Stream에서는 upgrade_type = default를 사용하고 모든 업데이트를 수용해야 합니다. 또한 Stream은 RHEL보다 앞서 나가므로, Rocky나 AlmaLinux에서 동일한 설정이 변경되는 것보다 Stream 환경에서 더 자주 변경됩니다.

Rocky 10과 AlmaLinux 10은 DNF5로 전환되면서 명칭이 변경되었습니다. 상위 DNF5 문서에 따르면 타이머는 dnf5-automatic.timer으로 제공되며, 기본값은 /usr/share/dnf5/dnf5-plugins/automatic.conf에 위치하고 사용자의 재정의 설정은 여전히 /etc/dnf/automatic.conf에 저장됩니다. 기본값인 download_updates는 no 대신 yes로 설정되며, upgrade_type로서 distro-sync이 추가되었습니다. 권고 사항 쿼리는 dnf advisory list이며, updateinfo은 별칭으로 유지됩니다. 버전 9를 기준으로 작성된 가이드의 패키지나 유닛 이름을 복사하기 전에, 실제 설치된 릴리스 버전을 확인하십시오.

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

이 주제와 관련하여 게시된 많은 가이드는 여전히 Rocky 8만을 다루고 있습니다. 해당 문서들이 작성된 이후 옵션 구성이 확장되었으므로, 오래된 기사를 맹신하기보다 자신의 서버에 있는 주석 처리된 파일을 직접 확인하십시오.

실패 모드와 확인 가능한 메시지

아무것도 실행되지 않습니다. systemctl list-timers dnf-automatic.timer는 빈 테이블을 출력하고 systemctl is-enabled dnf-automatic.timer는 disabled을 출력합니다. 패키지는 설치되었으나 타이머는 설치되지 않은 상태입니다.

작업이 실행되지만 아무것도 설치되지 않습니다. 저널에 No security updates needed, but 3 updates available이 기록됩니다. 보안 필터가 일치하는 항목을 찾지 못한 경우입니다. 보류 중인 항목에 권고 사항이 없거나, 저장소에서 권고 데이터를 게시하지 않았기 때문입니다.

설정이 무시되는 것처럼 보입니다. DNF는 automatic.conf의 알 수 없는 옵션을 디버그 수준에서 기록한 뒤 기본값을 사용합니다. 따라서 키를 잘못 입력해도 아무런 변화가 없으며 경고도 발생하지 않습니다. apply_update = yes를 작성해도 apply_updates은 no로 유지되므로, 시스템은 계속 다운로드만 수행하고 설치는 진행하지 않습니다. 편집 후에는 파일을 신뢰하는 대신 sudo systemctl start dnf-automatic.service를 실행하고 저널을 확인하십시오.

작업이 하루에 두 번 실행됩니다. 두 개의 타이머가 활성화된 상태입니다. systemctl list-unit-files 'dnf-automatic*'을 통해 어떤 타이머가 활성화되었는지 확인하십시오. 추가된 타이머가 설정 파일의 내용을 덮어쓰는 플래그를 전달하고 있을 수 있습니다.

메일이 도착하지 않습니다. email 발신자를 위해 포트 25에서 대기 중인 서비스가 없거나, send_error_messages가 여전히 no으로 설정되어 보고할 가치가 있는 유일한 내용이 오류뿐인 경우입니다.

패치된 서비스가 여전히 이전 버전을 보고합니다. 디스크의 파일은 새 버전이지만 메모리 상의 프로세스는 이전 버전입니다. dnf needs-restarting -s은 재시작이 필요한 서비스 목록을 보여줍니다.

FAQ

Rocky Linux에서 dnf-automatic은 보안 업데이트만 설치합니까?

/etc/dnf/automatic.conf 파일에서 upgrade_type = security을 설정하고, 저장소에서 errata 메타데이터를 제공하는 경우에만 그렇습니다. Rocky Linux와 AlmaLinux는 모두 이를 제공하므로 필터를 통해 권고 사항을 대조할 수 있습니다. 기본값은 upgrade_type = default이며, 이 경우 apply_updates = yes이 되면 사용 가능한 모든 업데이트를 설치합니다.

dnf-automatic이 "No security updates needed, but 3 updates available"이라고 보고하는 이유는 무엇입니까?

DNF는 저장소의 updateinfo.xml를 읽어 보안 업데이트 여부를 판단하며, 각 권고 사항에는 이를 해결하는 패키지 목록이 포함되어 있습니다. 메타데이터가 누락되었거나 오래된 경우 보안 필터는 아무것도 찾지 못하지만 일반 업데이트는 여전히 대기 상태로 남아 해당 메시지가 출력됩니다. 이는 errata를 전혀 게시하지 않는 CentOS Stream에서는 정상적인 현상입니다. Rocky나 AlmaLinux를 사용 중이라면 dnf updateinfo list --security과 dnf check-update를 비교하여 메타데이터가 최신인지 확인하십시오.

커널 업데이트 후 dnf-automatic이 서버를 재부팅합니까?

사용자가 설정하지 않는 한 재부팅하지 않습니다. reboot 옵션의 기본값은 never입니다. reboot = when-needed을 설정하면 dnf needs-restarting -r 검사 결과 kernel나 glibc 같은 핵심 패키지가 부팅 이후 교체된 경우에만 재부팅을 수행합니다. reboot = when-changed은 업데이트가 적용될 때마다 재부팅합니다. 두 경우 모두 reboot_command를 사용하며, 기본값은 shutdown -r +5으로 로그인한 사용자에게 경고 메시지를 보냅니다.

dnf-automatic 실행 시간을 변경하려면 어떻게 합니까?

sudo systemctl edit dnf-automatic.timer를 실행하고 OnCalendar= 줄을 비운 뒤 원하는 일정을 입력하는 [Timer] 섹션을 추가하십시오(예: OnCalendar=*-*-* 03:30). OnCalendar은 설정이 누적되므로 빈 줄을 넣지 않으면 기본값인 06:00 실행이 유지된 채 새로운 일정이 추가됩니다. systemctl list-timers dnf-automatic.timer를 실행하여 NEXT 열에서 변경 사항을 확인하십시오.

자동으로 패치되는 서버도 여전히 직접 확인해야 합니까?

그렇습니다. dnf-automatic은 패키지를 설치하는 역할만 수행합니다. 데몬을 재시작하지 않으며, emit_via에 실제로 확인 가능한 알림 수신자를 지정하지 않으면 아무런 보고도 받을 수 없습니다. 최소한 emit_via를 stdio으로 설정하고, send_error_messages를 활성화하여 실패 시 보고를 받도록 하며, 패치 작업 후 dnf needs-restarting -s를 실행하여 구버전 코드로 실행 중인 서비스가 있는지 확인해야 합니다.