dnfがaptと違うところ
한국어 원문으로 표시합니다.
한 줄 요약
dnf 의 결정적 차이는 모든 설치가 트랜잭션으로 기록되고 되돌릴 수 있다는 것이다. apt 에는 이에 대응하는 기능이 없다.
왜 이게 필요했나
우분투에서 넘어온 사람이 처음 놀라는 지점이 이것이다.
dnf history # 지금까지의 모든 트랜잭션 목록
dnf history info 42 # 42번 트랜잭션에서 무엇이 바뀌었나
dnf history undo 42 # 42번을 되돌린다
dnf history rollback 41 # 41번 시점의 상태로 되돌린다
apt 에는 /var/log/apt/history.log 라는 기록은 있지만 되돌리는 명령은 없다. 이 차이가 운영 방식을 바꾼다. RHEL 계열에서는 "일단 설치해 보고 아니면 되돌린다" 가 가능하다.
다만 한계가 명확하다. 이전 버전 패키지가 저장소에 없으면 다운그레이드가 실패한다. 그리고 Red Hat 은 시스템 패키지(selinux, selinux-policy, kernel, glibc 및 glibc 에 의존하는 gcc 등)의 다운그레이드를 지원하지 않는다고 명시한다. 롤백은 만능이 아니다.
어떻게 동작하나
명령 대응표
| 작업 | apt | dnf |
|---|---|---|
| 색인 갱신 | apt-get update |
(자동, 필요시 dnf makecache) |
| 설치 | apt-get install X |
dnf install X |
| 제거 | apt-get remove X |
dnf remove X |
| 검색 | apt-cache search X |
dnf search X |
| 정보 | apt-cache show X |
dnf info X |
| 파일→패키지 | dpkg -S /path |
dnf provides /path (미설치 포함) |
| 설치된 파일 목록 | dpkg -L X |
rpm -ql X |
| 업그레이드 | apt-get upgrade |
dnf upgrade |
| 버전 고정 | apt-mark hold |
dnf versionlock add |
| 롤백 | 없음 | dnf history undo |
dnf provides 가 특히 강력하다. apt 의 dpkg -S 는 이미 설치된 파일만 찾지만, dnf provides 는 저장소 메타데이터를 뒤져 아직 설치되지 않은 패키지까지 찾아 준다.
dnf provides '*/nginx.conf'
dnf provides 'libnl-3.so.200()(64bit)'
두 번째 예시가 중요하다. RPM 에서 의존성의 단위는 패키지 이름이 아니라 능력(capability) 이다. 공유 라이브러리의 소네임, 파일 경로, 심지어 심볼 버전까지 의존 대상이 될 수 있다.
dnf repoquery --requires httpd
dnf repoquery --requires --resolve --recursive httpd | sort -u | wc -l
--requires 는 요구하는 능력, --resolve 는 그 능력을 제공하는 패키지로 치환, --recursive 는 재귀적으로 계속 내려간다. 폐쇄망 반입 목록을 만들 때 핵심 도구다.
저장소 파일
# /etc/yum.repos.d/labhub-local.repo
[labhub-local]
name=LabHub local (snapshot 2026-08-20)
baseurl=file:///srv/repo/labhub
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-labhub
metadata_expire=-1
각 키의 기본값을 알아 두는 것이 중요하다.
enabled기본 Truegpgcheck기본 False — 명시적으로 켜야 한다repo_gpgcheck(메타데이터 서명 검증) 기본 Falsepriority기본 99metadata_expire기본 48시간. 폐쇄망 로컬 저장소에서는-1(만료 없음)로 두는 편이 낫다module_hotfixes기본 False
저장소 표시 이름에 스냅샷 날짜를 박아 두면 6개월 뒤 dnf repolist -v 한 줄로 그 서버가 언제 시점 콘텐츠로 설치됐는지 알 수 있다.
캐시
폐쇄망에서 가장 많은 신고가 "저장소에 패키지를 넣었는데 안 보인다" 다. 원인은 둘 중 하나다.
# 저장소 쪽: 메타데이터를 다시 만들었는가 (이걸 빼먹는 경우가 정말 많다)
createrepo_c --update /srv/repo/labhub
# 클라이언트 쪽: 캐시를 만료 표시 (가장 가벼움)
dnf clean expire-cache
# 그래도 안 되면
dnf clean metadata
# 최후의 수단
dnf clean all
dnf makecache
각각의 정의: expire-cache 는 메타데이터를 만료 표시만, metadata 는 메타데이터 제거, packages 는 캐시된 패키지 제거, all 은 전부.
현장에서 만나는 모습
dnf update --security 가 조용히 "할 일 없음" 으로 끝나는 경우. 보안 권고(updateinfo) 메타데이터가 저장소에 없으면 그렇게 된다. createrepo_c 는 rpm 파일에서 primary/filelists/other 만 만들 수 있고, 권고 정보는 rpm 안에 없다. 조용히 아무것도 하지 않는다는 점이 위험하다. dnf updateinfo --summary 로 확인하는 습관이 필요하다.
다음 실습에서 할 것
dnf 로 저장소를 확인하고, 설치하고, provides 로 역추적하고, 히스토리로 롤백하고, 버전을 고정한다.