Haru Utils

LINUX BASELINE

Linux 버전 확인과 지원 상태 점검

설치나 서버 설정 변경 없이 배포판·커널·아키텍처·가상화 환경과 실제 업데이트 채널을 확인하고, 공식 지원 수명주기와 대조해 업그레이드 필요성을 판단합니다.
리눅스 버전 확인Linux EOL 확인os-release커널 버전 확인Linux 배포판 확인Ubuntu RHEL Debian 지원 종료
지원 환경/etc/os-release 또는 /usr/lib/os-release를 제공하는 일반 Linux 배포판
예상 시간15
난이도초급
검토일2026-08-28

BEFORE YOU START

시작 전에 준비하세요

01

조회할 Linux 서버의 일반 사용자 셸(기본 진단에는 sudo가 필요하지 않음)

02

출력을 안전하게 보관할 개인 작업 공간과 점검 기준 시각

03

배포판 공급사의 공식 수명주기 페이지를 열 수 있는 별도 브라우저

04

컨테이너라면 이미지 정보와 호스트 정보를 구분할 수 있는 운영 문서

권장 대상 운영 중인 Linux 서버의 정확한 버전과 지원 종료 여부를 확인하고 업그레이드 우선순위를 정하려는 개발자·운영자

FOLLOW THE RECIPE

8단계 구성·점검 레시피

1
확인시스템을 변경하지 않는 점검 단계

점검 범위와 기준 시각 고정

이 레시피는 버전과 지원 상태를 읽기 전용으로 확인합니다. 패키지 설치·업데이트·재부팅은 수행하지 않으며, 먼저 UTC 기준 시각과 실행 위치가 호스트인지 컨테이너인지 기록합니다.

점검 기준 시각
date -u '+%Y-%m-%dT%H:%M:%SZ'
가상화·컨테이너 감지
if command -v systemd-detect-virt >/dev/null 2>&1; then systemd-detect-virt || printf '%s\n' 'none 또는 감지되지 않음'; else printf '%s\n' 'systemd-detect-virt 없음'; fi
none이나 비제로 종료는 베어메탈 또는 감지 불가일 수 있으며 그 자체가 오류는 아닙니다.
프로세스 1과 cgroup 단서
ps -p 1 -o comm=
sed -n '1,20p' /proc/1/cgroup
컨테이너 런타임에 따라 명확한 이름이 나오지 않을 수도 있습니다.
  • 점검 시각을 기록했습니다.
  • 호스트·VM·컨테이너 중 어디에서 실행했는지 구분했습니다.
  • 공유 전 내부 경로와 cgroup 식별자를 가릴 준비를 했습니다.
결과 읽기

컨테이너 안의 /etc/os-release는 보통 이미지 배포판을, uname은 호스트가 제공한 커널을 나타냅니다. 두 결과가 달라도 이상으로 단정하지 않습니다.

다음 판단

배포판이 제공하는 표준 식별 파일에서 ID와 VERSION_ID를 읽습니다.

2
확인시스템을 변경하지 않는 점검 단계

배포판과 릴리스 식별

표준 os-release 파일을 우선순위에 따라 읽습니다. 자동 판별에는 ID와 VERSION_ID를 사용하고, PRETTY_NAME은 사람에게 보여 주는 이름, ID_LIKE는 알 수 없는 배포판의 보조 단서로만 사용합니다.

표준 배포판 정보
if [ -r /etc/os-release ]; then grep -E '^(PRETTY_NAME|ID|ID_LIKE|VERSION_ID|VERSION_CODENAME|VARIANT_ID|BUILD_ID)=' /etc/os-release; elif [ -r /usr/lib/os-release ]; then grep -E '^(PRETTY_NAME|ID|ID_LIKE|VERSION_ID|VERSION_CODENAME|VARIANT_ID|BUILD_ID)=' /usr/lib/os-release; else printf '%s\n' 'os-release 파일을 찾지 못했습니다.'; fi
호스트 배포판 정보(제공되는 컨테이너만)
if [ -r /run/host/os-release ]; then grep -E '^(PRETTY_NAME|ID|VERSION_ID)=' /run/host/os-release; else printf '%s\n' '호스트 os-release가 노출되지 않음'; fi
파일이 없다는 이유만으로 컨테이너가 아니라고 판정하지 않습니다.
배포판 식별값만 정리
if [ -r /etc/os-release ]; then . /etc/os-release; elif [ -r /usr/lib/os-release ]; then . /usr/lib/os-release; else exit 1; fi
printf 'ID=%s\nVERSION_ID=%s\nID_LIKE=%s\n' "${ID:-unknown}" "${VERSION_ID:-rolling-or-unknown}" "${ID_LIKE:-none}"
  • ID와 VERSION_ID를 기록했습니다.
  • VERSION_ID가 없을 수 있는 rolling release인지 확인했습니다.
  • 컨테이너 이미지와 호스트 OS를 하나의 버전으로 섞지 않았습니다.
결과 읽기

uname -r은 배포판 버전이 아닙니다. os-release가 없거나 ID가 unknown이면 커널 문자열만 보고 배포판을 추측하지 말고 이미지 명세나 공급사 문서를 확인합니다.

다음 판단

현재 실행 중인 커널과 사용자 공간 아키텍처를 별도로 확인합니다.

3
확인시스템을 변경하지 않는 점검 단계

추가 설치 없이 커널·아키텍처 확인

단계 구조상 설치 단계이지만 새 패키지는 설치하지 않습니다. 기본 명령이 제공하는 커널 릴리스, 머신 아키텍처, 사용자 공간 비트 수를 각각 확인합니다.

커널 이름·릴리스·아키텍처
uname -s
uname -r
uname -m
사용자 공간 비트 수
getconf LONG_BIT
CPU 전체 능력이 아니라 현재 사용자 공간 실행 환경에서 long 형식이 사용하는 비트 수입니다.
배포판 패키지 아키텍처
if command -v dpkg >/dev/null 2>&1; then dpkg --print-architecture; elif command -v rpm >/dev/null 2>&1; then rpm --eval '%{_arch}'; elif command -v apk >/dev/null 2>&1; then apk --print-arch; else printf '%s\n' '패키지 아키텍처 조회 명령 없음'; fi
기본 조회 도구 존재 확인
command -v sh cat grep sed uname getconf
일부 최소 이미지에서 getconf가 없을 수 있으며, 이 가이드를 위해 패키지를 추가하지 않아도 됩니다.
  • 배포판 버전과 커널 릴리스를 서로 다른 값으로 기록했습니다.
  • x86_64·aarch64 같은 머신 아키텍처와 패키지 아키텍처를 구분했습니다.
  • 기본 도구가 없는 최소 이미지에서도 설치를 강행하지 않았습니다.
결과 읽기

x86_64와 amd64, aarch64와 arm64는 도구마다 다른 이름을 사용할 수 있습니다. 값이 다르게 보이면 애플리케이션 패키지가 요구하는 표기 체계를 기준으로 호환성을 다시 확인합니다.

다음 판단

패키지 관리자와 init 체계를 읽기 전용으로 확인합니다.

4
확인시스템을 변경하지 않는 점검 단계

실행 환경과 패키지 체계 식별

시스템 설정을 바꾸지 않고 패키지 관리자, init 프로세스, WSL 여부를 확인합니다. 읽기 전용 점검이므로 설정 백업이나 복원 파일을 만들 필요가 없습니다.

패키지 관리자 후보
for pm in apt-get dnf yum zypper apk pacman; do command -v "$pm" >/dev/null 2>&1 && printf '%s\n' "$pm"; done
여러 관리자가 함께 표시될 수 있으므로 이 결과만으로 배포판을 판정하지 않습니다.
init 체계
if [ -r /proc/1/comm ]; then cat /proc/1/comm; else printf '%s\n' 'PID 1 이름을 읽을 수 없음'; fi
실행 인자에는 토큰이나 접속 문자열이 들어갈 수 있어 조회하지 않습니다.
WSL 환경 단서
if grep -qi microsoft /proc/sys/kernel/osrelease 2>/dev/null; then printf '%s\n' 'WSL 단서가 감지됨'; else printf '%s\n' 'WSL 단서 없음'; fi
감지 결과는 보조 단서이며 최종 환경 식별은 운영 자산 정보와 함께 확인합니다.
os-release 제공 패키지
if command -v dpkg-query >/dev/null 2>&1; then dpkg-query -S /etc/os-release 2>/dev/null; elif command -v rpm >/dev/null 2>&1; then rpm -qf /etc/os-release 2>/dev/null; elif command -v apk >/dev/null 2>&1; then apk info --who-owns /etc/os-release 2>/dev/null; elif command -v pacman >/dev/null 2>&1; then pacman -Qo /etc/os-release 2>/dev/null; else printf '%s\n' '패키지 소유자 조회 방식 확인 필요'; fi
  • 패키지 관리자를 배포판 판별의 유일한 근거로 사용하지 않았습니다.
  • 컨테이너·WSL·chroot 가능성을 운영 환경 정보와 함께 확인했습니다.
  • 시스템 파일과 서비스 설정을 변경하지 않았고 백업 파일도 만들지 않았습니다.
결과 읽기

Amazon Linux 2023처럼 yum이 dnf 호환 진입점인 경우도 있고 도구가 공존할 수도 있습니다. 최종 식별값은 os-release의 ID와 VERSION_ID입니다.

다음 판단

배포판에 맞는 조회 명령만 선택해 실제 업데이트·구독 채널을 확인합니다.

5
확인시스템을 변경하지 않는 점검 단계

배포판별 지원 채널 조회

아래 묶음 중 확인된 배포판에 해당하는 읽기 전용 명령만 실행합니다. 저장소 주소에는 내부 도메인이나 자격정보가 포함될 수 있으므로 원문을 공개 게시하지 않습니다.

Ubuntu·Debian 계열
command -v pro >/dev/null 2>&1 && pro status
command -v pro >/dev/null 2>&1 && pro security-status
command -v apt-cache >/dev/null 2>&1 && apt-cache policy
Debian에서는 pro 명령이 없는 것이 정상입니다. check-support-status가 이미 설치돼 있다면 별도로 실행할 수 있습니다.
RHEL 계열 구독·저장소
command -v subscription-manager >/dev/null 2>&1 && subscription-manager status
command -v subscription-manager >/dev/null 2>&1 && subscription-manager repos --list-enabled
if command -v dnf >/dev/null 2>&1; then dnf repolist --enabled; elif command -v yum >/dev/null 2>&1; then yum repolist enabled; fi
Simple Content Access 환경에서는 상태 문구와 활성 저장소를 함께 해석합니다. identity 명령은 시스템 UUID와 조직 정보를 노출할 수 있어 제외했습니다.
Amazon Linux 2023 패키지 지원
command -v dnf >/dev/null 2>&1 && dnf supportinfo --show installed
해당 하위 명령을 지원하지 않으면 공식 AL2023 문서에서 동일 버전의 패키지 지원 정보를 확인합니다.
SLES 제품·저장소
command -v SUSEConnect >/dev/null 2>&1 && SUSEConnect -s
command -v zypper >/dev/null 2>&1 && zypper repos -u
  • os-release에서 확인한 배포판에 맞는 명령만 실행했습니다.
  • 활성 보안 저장소와 구독·확장 지원 상태를 따로 기록했습니다.
  • 공유할 출력에서 내부 미러 주소·쿼리 토큰·조직 정보를 제거했습니다.
결과 읽기

저장소에 접속된다는 사실만으로 공식 지원 중이라고 판정할 수 없습니다. 반대로 구독 상태 한 줄만으로 업데이트 사용 가능 여부를 단정하지 말고 활성 저장소와 공급사 설명을 함께 봅니다.

다음 판단

ID와 VERSION_ID, 현재 날짜를 공급사의 공식 수명주기 페이지와 대조합니다.

6
주의권한·연결·중단 영향을 확인할 단계

공식 수명주기와 교차 검증

현재 버전 번호를 외부 요약 글과 비교하지 말고 하단의 공식 공급사 페이지에서 직접 확인합니다. major 버전뿐 아니라 minor·Service Pack·아키텍처·패키지 범위와 유료 확장 지원 조건을 함께 봅니다.

비교할 식별값과 날짜
if [ -r /etc/os-release ]; then . /etc/os-release; elif [ -r /usr/lib/os-release ]; then . /usr/lib/os-release; else exit 1; fi
printf 'ID=%s\nVERSION_ID=%s\n' "${ID:-unknown}" "${VERSION_ID:-rolling-or-unknown}"
date -u '+CHECKED_AT=%Y-%m-%dT%H:%M:%SZ'
현재 실행 커널 재확인
printf 'RUNNING_KERNEL=%s\n' "$(uname -r)"
설치된 커널 패키지 단서
if command -v dpkg-query >/dev/null 2>&1; then dpkg-query -W 'linux-image-*' 2>/dev/null; elif command -v rpm >/dev/null 2>&1; then rpm -qa 'kernel*'; elif command -v apk >/dev/null 2>&1; then apk info -vv | grep '^linux-'; else printf '%s\n' '커널 패키지 조회 방식 확인 필요'; fi
실행 중 커널과 가장 최근 설치 패키지가 다르면 재부팅 계획 여부를 별도로 확인합니다.
  • 공식 공급사 페이지에서 정확한 ID·VERSION_ID의 지원 상태를 확인했습니다.
  • 표준 지원과 ESM·LTS·LTSS 같은 확장 지원의 범위·계약 조건을 구분했습니다.
  • Rocky·Alma 계열은 major뿐 아니라 현재 minor 지원 여부도 확인했습니다.
  • Amazon Linux는 OS 수명주기와 개별 패키지 지원 기간을 구분했습니다.
  • 컨테이너 이미지 지원 상태와 호스트 커널 지원 상태를 각각 확인했습니다.
결과 읽기

엔터프라이즈 배포판은 보안 패치를 기존 버전에 backport할 수 있습니다. upstream 버전 숫자가 낮아 보인다는 이유만으로 취약하거나 미지원이라고 판단하지 말고 공급사 보안 공지와 패키지 릴리스를 기준으로 봅니다.

다음 판단

공식 수명주기와 실제 업데이트 채널을 함께 사용해 정상·주의·업그레이드 필요로 분류합니다.

7
주의권한·연결·중단 영향을 확인할 단계

보안 업데이트와 업그레이드 필요성 판정

배포판에 맞는 읽기 전용 명령으로 보안 지원 범위와 업데이트 공지를 확인합니다. 빈 결과는 지원 중이라는 증거가 아니며 저장소 메타데이터의 최신성과 구독 범위를 함께 확인해야 합니다.

Ubuntu 보안 상태
if command -v pro >/dev/null 2>&1; then pro security-status; else printf '%s\n' 'Ubuntu Pro Client 없음'; fi
Ubuntu에서만 실행합니다. 출력의 서비스·패키지 범위와 ESM 활성 여부를 함께 해석합니다.
Debian 패키지별 지원 예외
if command -v check-support-status >/dev/null 2>&1; then check-support-status; else printf '%s\n' 'debian-security-support 도구 없음'; fi
Debian에서만 실행합니다. 도구가 이미 설치된 경우 지원이 제한되거나 조기 종료된 패키지를 보여 줍니다.
RHEL·Rocky·Alma·Amazon Linux 보안 공지
if command -v dnf >/dev/null 2>&1; then dnf updateinfo list --security; elif command -v yum >/dev/null 2>&1; then yum updateinfo list security; else printf '%s\n' 'DNF/YUM 보안 공지 조회 명령 없음'; fi
RHEL 계열에서만 실행합니다. 구독·저장소 메타데이터 상태에 따라 결과 범위가 달라집니다.
SLES 보안 패치
if command -v zypper >/dev/null 2>&1; then zypper list-patches --category security; else printf '%s\n' 'zypper 없음'; fi
SLES에서만 실행합니다. 일부 조회는 저장소에 읽기 요청을 보내지만 패키지를 변경하지 않습니다.
재부팅 필요 신호
if [ -r /var/run/reboot-required ]; then cat /var/run/reboot-required; else printf '%s\n' '배포판 표준 재부팅 신호 없음'; fi
이 파일이 없는 배포판도 있으므로 없음이 재부팅 불필요를 보장하지 않습니다.
실패한 systemd unit
if [ -r /proc/1/comm ] && [ "$(cat /proc/1/comm)" = systemd ] && command -v systemctl >/dev/null 2>&1; then systemctl --failed --no-pager; else printf '%s\n' 'systemd가 PID 1로 실행 중인 환경이 아님'; fi
  • 공식 지원 기간 안이고 필요한 보안 채널이 활성화된 경우에만 정상으로 분류했습니다.
  • 확장 지원 계약·컨테이너 호스트·저장소 최신성이 불명확하면 주의로 분류했습니다.
  • EOL이거나 공식 보안 저장소가 없고 현재 minor·SP가 미지원이면 업그레이드 필요로 분류했습니다.
  • 버전 숫자만 보고 패키지 취약 여부를 단정하지 않았습니다.
결과 읽기

업데이트 후보가 0개여도 EOL 저장소가 멈췄거나 메타데이터가 오래된 상태일 수 있습니다. 공식 lifecycle, 활성 보안 채널, 최신 메타데이터 세 조건이 모두 확인돼야 합니다.

다음 판단

업그레이드가 필요해도 이 가이드에서 즉시 실행하지 않고 중단 조건과 복구 준비를 확인합니다.

8
확인시스템을 변경하지 않는 점검 단계

진단 종료와 업그레이드 판단 롤백

이 레시피는 시스템을 변경하지 않았으므로 패키지 롤백은 필요하지 않습니다. 판별이 불확실하거나 복구 준비가 없으면 업그레이드 판단을 되돌리고 읽기 전용 상태로 점검을 종료합니다.

점검 종료 시각
date -u '+%Y-%m-%dT%H:%M:%SZ'
실행 환경 최종 재확인
if command -v systemd-detect-virt >/dev/null 2>&1; then systemd-detect-virt || printf '%s\n' 'none 또는 감지되지 않음'; else printf '%s\n' 'systemd-detect-virt 없음'; fi
현재 식별값 최종 재확인
if [ -r /etc/os-release ]; then cat /etc/os-release; elif [ -r /usr/lib/os-release ]; then cat /usr/lib/os-release; else printf '%s\n' 'os-release 파일을 찾지 못했습니다.'; fi
uname -srmo
  • 이 가이드에서 패키지·서비스·부트 설정을 변경하지 않았음을 확인했습니다.
  • 지원되는 업그레이드 경로와 중간 hop을 공식 문서에서 확인하지 못했다면 작업을 중단했습니다.
  • 복구 콘솔, 검증된 백업·복원, 디스크 여유, 핵심 서비스 점검표가 없으면 업그레이드를 시작하지 않았습니다.
  • 컨테이너·immutable 환경은 실행 중 수정 대신 기반 이미지 재빌드와 교체 계획으로 전환했습니다.
결과 읽기

일반적인 패키지 downgrade를 범용 롤백으로 사용하지 않습니다. 실제 업그레이드는 배포판별 공식 절차와 검증된 이미지·백업 복구 계획을 갖춘 별도 변경 작업으로 진행합니다.

다음 판단

업그레이드 계획이 승인되면 완료 후 이 레시피를 다시 실행해 배포판·커널·저장소·서비스 기준값을 비교합니다.

SECURITY CHECK

운영 전 마지막 보안 점검

  • 기본 진단은 sudo 없이 실행하고 이 가이드에서 설치·업데이트·재부팅 명령을 실행하지 않습니다.
  • 공유 출력에서는 내부 경로, cgroup 식별자, 미러 주소, 조직 정보와 쿼리 토큰을 가립니다.
  • 배포판 버전은 os-release, 커널 버전은 uname으로 분리해 기록합니다.
  • 저장소 접속이나 낮은 upstream 버전만으로 지원·취약 여부를 단정하지 않습니다.
  • 표준 지원과 유료·제한형 확장 지원의 패키지·아키텍처 범위를 확인합니다.
  • 실제 업그레이드는 복구 콘솔, 검증된 백업, 애플리케이션 호환성, 점검 시간과 롤백 계획을 갖춘 별도 작업으로 진행합니다.

COMMON ERRORS

자주 막히는 지점

os-release 파일을 찾지 못함

증상
표준 경로 두 곳 모두 없거나 필수 ID가 비어 있습니다.
가능한 원인
매우 오래된 배포판, 최소 복구 이미지, 손상된 루트 파일시스템 또는 특수 어플라이언스일 수 있습니다.
확인 순서
uname만으로 배포판을 추측하지 말고 이미지 명세·패키지 DB·공급사 콘솔에서 제품을 식별한 뒤 지원팀 문서와 대조합니다.

컨테이너 배포판과 커널 버전이 어울리지 않음

증상
예를 들어 컨테이너의 배포판은 최신인데 uname에는 다른 계열에서 관리하는 커널이 표시됩니다.
가능한 원인
컨테이너는 사용자 공간 파일을 이미지에서 가져오고 커널은 호스트와 공유합니다.
확인 순서
이미지 ID·태그·digest와 호스트 OS를 별도 자산으로 기록하고 각각의 지원 상태를 확인합니다.
트러블슈팅으로 이어보기

커널 숫자가 오래돼 보여 취약하다고 판단됨

증상
취약점 보고서가 upstream 버전만 비교해 패치되지 않은 것으로 표시합니다.
가능한 원인
배포판 공급사가 보안 수정만 기존 패키지 릴리스에 backport했을 수 있습니다.
확인 순서
공급사의 CVE·보안 공지와 설치된 전체 패키지 release를 대조하고 버전 문자열만으로 결론내리지 않습니다.

저장소는 열리지만 지원 여부가 불명확함

증상
패키지 목록은 조회되지만 공식 lifecycle에서 같은 버전이나 minor를 찾기 어렵습니다.
가능한 원인
EOL 저장소·vault·내부 미러가 계속 응답하거나 확장 지원 계약 범위가 다를 수 있습니다.
확인 순서
ID·VERSION_ID·minor·아키텍처와 구독 상태를 공급사 lifecycle에서 확인하고 불명확하면 업그레이드를 보류합니다.
트러블슈팅으로 이어보기

업데이트 뒤 실행 커널이 바뀌지 않음

증상
설치된 커널 패키지와 uname -r 결과가 다르고 재부팅 필요 신호가 보입니다.
가능한 원인
새 커널이 설치됐지만 아직 재부팅하지 않았거나 부트 항목이 이전 커널을 선택했을 수 있습니다.
확인 순서
즉시 재부팅하지 말고 점검 시간·콘솔 복구·부트로더 상태와 핵심 서비스 검증 계획을 먼저 준비합니다.
트러블슈팅으로 이어보기

PRIMARY REFERENCES

공식 문서

설치 저장소와 지원 버전은 바뀔 수 있습니다. 검토일 이후에는 링크된 공식 문서와 현재 서버의 패키지 후보 버전을 함께 확인하세요.

도구 빠른 검색

최근 사용한 도구를 다시 열거나, 이름과 기능으로 검색하세요.

검색어와 도구의 입력·결과는 저장하지 않습니다.

↑↓ 이동 · Enter 열기 · Esc 닫기