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에서는 별도의 아카이브 저장소를 사용하지만, RHEL 계열에서는 게시된 권고 사항(advisory)에 첨부된 메타데이터를 사용합니다. 이 메타데이터는 누락되거나 최신 상태가 아닐 수 있습니다. 권고 데이터가 없는 저장소를 dnf-automatic이 참조하도록 설정하면, 아무것도 설치하지 않으면서 성공했다고 보고할 수 있습니다.

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

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

자동 업데이트 활성화는 새 VPS 설정의 첫 10분 과정에서 root가 아닌 사용자 계정 생성 및 방화벽 설정 직후에 수행해야 합니다. 방화벽 설정이 아직 완료되지 않았다면, Rocky 및 AlmaLinux에서 기본으로 제공하는 firewalld를 사용하십시오. 몇 가지 명령어로 SSH와 서비스 포트를 개방하고 재부팅 후에도 설정이 유지되도록 할 수 있습니다.

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: 보안 권고 사항에 명시된 패키지만 설치됩니다.

외부에 노출된 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는 모두 이를 게시하므로, 이 두 OS에서 목록이 비어 있다면 대개는 정상적인 상황입니다. 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 이미터는 보고서를 사용자가 지정한 프로그램의 표준 입력으로 전달합니다.

[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 데몬을 재시작하십시오. 새로운 커널은 실행 중인 커널을 즉석에서 교체할 수 없으므로 재부팅만이 유일한 해결책입니다. 특정 날짜의 업데이트를 재부팅이 필요한 경우와 서비스 재시작만으로 충분한 경우로 분류하고 싶다면, 어떤 업데이트가 재부팅을 필요로 하고 어떤 업데이트가 서비스 재시작만 필요한지 문서를 통해 패키지별로 확인하십시오.

컨테이너는 별개의 문제입니다. dnf-automatic은 호스트의 패키지만 패치할 뿐 이미지 내부에 포함된 사용자 공간(userland)은 건드리지 않기 때문입니다. 따라서 Rocky Linux 또는 AlmaLinux에서 Docker Engine을 실행하는 서버는 실제 트래픽을 처리하는 코드에 수정 사항이 반영되도록 이미지를 다시 내려받고 컨테이너를 재생성해야 합니다.

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

[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를 사용하여 데이터를 필터링할 수 있습니다. 앞서 언급한 Rocky의 오래된 에러타 데이터는 두 배포판의 일상적인 동작이 달라지는 몇 안 되는 지점 중 하나입니다. 따라서 아직 서버를 구축하기 전이라면 두 배포판을 구분 짓는 호환성 약속 및 구형 CPU 지원을 함께 고려하십시오.

CentOS Stream은 예외이며, 다루기 까다로운 대상입니다. Stream 저장소는 updateinfo.xml를 제공하지 않으므로 보안 필터가 일치할 수 없으며, 실행할 때마다 No security updates needed가 보고됩니다. Stream에서는 upgrade_type = default를 사용하고 모든 업데이트를 수용해야 합니다. 또한 Stream은 RHEL보다 앞서 나가므로, Rocky나 AlmaLinux에서 동일한 설정이 유지되는 것과 달리 Stream 서버에서는 설정이 더 자주 변경됩니다. 이러한 차이는 패키징 과정의 우연이 아니라, 2020년 Red Hat이 CentOS를 RHEL의 롤링 프리뷰 버전으로 전환하기로 한 결정의 결과이며, 이는 Rocky Linux와 AlmaLinux가 탄생하게 된 계기이기도 합니다.

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이 "보안 업데이트는 필요 없지만 3개의 업데이트가 있습니다"라고 보고하는 이유는 무엇입니까?

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를 실행하여 여전히 이전 코드로 동작 중인 서비스를 확인해야 합니다.