배포판·패키지와 실행 환경

01배포판의 사용자 공간과 실행 중인 커널을 구별하기

• 커널·패키지Linux라는 커널을 공통으로 사용해도 패키지 형식, 기본 경로, 서비스 이름, 저장소, 보안 정책은 배포판마다 다르다.
• 배포판 식별 필드/etc/os-release의 ID는 배포판 식별자, ID_LIKE는 호환 계열, VERSION_ID는 배포판 릴리스를 뜻한다.
• unameuname -r은 현재 실행 중인 커널 버전이다.
• 사용자 공간·커널컨테이너에서는 사용자 공간이 Ubuntu여도 커널은 호스트의 것을 공유하므로 두 출력이 서로 다른 계열을 가리킬 수 있다.
• 저장소RPM을 사용하는 RHEL·Rocky·Fedora가 모두 같은 저장소와 수명주기를 갖는 것은 아니다.

  • Debian·Ubuntu는 dpkg와 APT 계열을 사용한다.
• 패키지CPU 아키텍처도 패키지 선택의 일부이며 x86_64용 바이너리를 aarch64 시스템에 복사했다고 바로 실행할 수 있는 것은 아니다.
• 설치 환경의 좌표배포판·릴리스·아키텍처는 설치 절차를 선택하는 좌표다.

cat /etc/os-release
uname -r
uname -m
command -v rpm
command -v dpkg

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

02패키지 파일, 설치 데이터베이스, 저장소 관리자의 관계

• 패키지 메타데이터패키지에는 프로그램 파일과 함께 이름·버전·아키텍처·의존성·설치 스크립트·설정 파일 정보 같은 메타데이터가 들어간다.
• rpm·dpkgrpm이나 dpkg는 로컬 패키지를 설치하고 설치 데이터베이스를 관리하는 기반 도구다.
• 저장소·메타데이터DNF와 APT는 저장소 메타데이터를 조회하고 의존 관계를 해결하여 여러 패키지를 하나의 설치 계획으로 묶는다.
• 수동 설치와 저장소 관리패키지 파일 하나를 수동으로 설치하는 작업과 저장소에서 필요한 구성 요소를 함께 선택하는 작업의 층이 다르다.

  • 예를 들어 웹 서버 패키지가 특정 공유 라이브러리를 필요로 하면 관리자는 현재 설치 상태와 저장소의 후보 버전을 비교해 충족 가능한 조합을 찾는다.
• 변경 목록 계산내려받기 전에 설치·업그레이드·제거 예정 목록을 보여 주는 이유가 여기에 있다.
• 저장소·서명저장소 서명과 패키지 서명 검증은 신뢰한 배포자가 제공한 자료인지 검사하는 부분이며, 단순히 파일이 다운로드되었다는 사실과 구별된다.
• 저장소·의존성서로 다른 릴리스의 저장소를 섞으면 의존성을 형식상 충족해도 ABI와 배포판 지원 관계가 깨질 수 있다.

03패키지 갱신, 제거와 설정 파일의 수명

• 저장소·메타데이터저장소 메타데이터 갱신은 이용 가능한 버전 목록을 새로 받는 작업이다.
• aptDebian 계열의 apt update는 이 단계이며 실제 설치된 패키지 업그레이드와 다르다.
• 실행 중인 이전 코드설치된 바이너리가 바뀌어도 실행 중인 프로세스는 이전 inode나 이미 매핑된 라이브러리를 사용할 수 있다.
• 패키지·커널그래서 패키지 갱신과 서비스 재시작, 커널 갱신과 새 커널로 재부팅하는 단계를 구별해야 한다.
• 패키지·의존성제거할 패키지가 다른 패키지의 의존성으로 사용되면 함께 영향을 받는 범위를 계산한다.
• 의존성자동으로 설치된 의존성을 정리하는 autoremove는 의존성 기록에 기초하므로 사람이 실제로 사용하는 프로그램까지 자동 설치 상태로 남겨 두지 않았는지 의미를 이해해야 한다.

  • 설정 파일 보존 방식도 도구마다 다르다.
• 최종 동작 설정배포판의 기본 파일과 관리자가 수정한 파일이 충돌하면 별도 새 파일을 남기거나 선택을 요구할 수 있으므로 업그레이드를 모든 설정의 무조건 덮어쓰기로 생각하지 않는다.

# RHEL 계열의 조회 예시
dnf repolist
dnf info bash
rpm -q bash
rpm -ql bash
# Debian 계열의 조회 예시
apt-cache policy bash
dpkg-query -L bash

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

04명령 이름에서 실제 실행 파일까지 추적하기

• 명령 이름과 실행 대상셸에 입력한 이름이 곧 디스크 파일이라고 단정할 수 없다.
• PATH·명령alias, 함수, builtin, 해시된 경로, PATH 검색이 명령 해석에 관여한다.
• 명령 후보 조회Bash에서 type -a는 여러 후보를 보여 주고 command -v는 현재 해석 결과를 알려 준다.
• whichwhich는 별도 프로그램이라 셸의 함수나 별칭 상태를 완전히 반영하지 못할 수 있다.
• 링크·Alternatives경로가 확인되어도 심볼릭 링크를 따라간 실제 파일과 alternatives가 선택한 구현을 다시 구분한다.
• 패키지·rpm프로그램 파일의 소유 패키지는 rpm -qf 또는 dpkg -S로 찾는다.
• 배포판/usr/local/bin에 수동 설치한 파일은 배포판 데이터베이스에 없을 수 있다.
• PATH인터랙티브 셸과 systemd 서비스는 PATH와 환경 변수가 다를 수 있으므로 서비스의 ExecStart와 /proc/PID/exe가 실제 실행 대상을 보여 준다.
• 서비스의 실제 버전파일이 교체된 뒤 이전 프로세스가 남아 있는 경우에는 버전 명령만 새 셸에서 실행해서는 현재 서비스의 버전을 설명할 수 없다.

type -a python3
command -v python3
readlink -f /usr/bin/python3
systemctl show demo.service -p ExecStart -p MainPID

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

05공유 라이브러리와 Python 패키지를 혼동하지 않기

• 공유 라이브러리동적 실행 파일은 로더가 필요한 공유 라이브러리를 찾은 뒤 실행을 이어 간다.
• 실행 파일과 라이브러리실행 파일 자체의 위치가 맞아도 필요한 라이브러리나 호환 심볼이 없으면 적재가 실패할 수 있다.
• 캐시readelf -d의 NEEDED 항목은 필요한 라이브러리를 정적으로 살펴보는 방법이고, ldconfig 캐시는 시스템 라이브러리 검색에 관여한다.

  • 신뢰하지 않는 실행 파일에 분석 도구를 적용할 때는 그 도구가 파일을 실제로 실행할 수 있는지도 구분한다.
• Python 모듈Python 모듈은 인터프리터의 sys.path에서 찾는다.
• 배포판가상 환경, 사용자 설치, 배포판 설치가 섞이면 같은 import 이름으로 다른 버전이 선택될 수 있다.
• pippython3 -m pip는 그 python3에 연결된 pip를 사용한다는 의미다.
• 패키지운영체제 패키지 관리자는 시스템 구성 요소의 의존성을 관리하고 Python 가상 환경은 프로젝트의 모듈 집합을 분리하므로 두 범위를 한 디렉터리에서 무분별하게 덮어쓰지 않는다.

readelf -d /usr/bin/ls
python3 -m pip show requests
python3 -c "import sys; print(sys.executable); print(*sys.path, sep=chr(10))"

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

06Anaconda·conda와 실제 Python 실행 환경

• 배포 제품과 관리자Anaconda Distribution은 Python·conda·분석 패키지 등을 묶은 배포 제품이다. conda는 그 안에서도 사용되는 패키지·환경 관리자이며 Python 언어나 VM 자체가 아니다.
• 환경별 설치 경로환경은 서로 다른 실행기·패키지 조합을 별도 경로로 관리한다. 한 환경에 설치한 모듈이 다른 환경의 Python에서도 자동으로 보이는 것은 아니다.
• 활성화의 범위conda activate는 현재 셸의 PATH와 환경 변수 등을 조정한다. 기존 서비스나 다른 터미널, 이미 떠 있는 Notebook 커널의 실행기를 자동 교체하지 않는다.
• base 표시 읽기프롬프트의 (base)는 기본 환경이 활성화됐다는 표시일 수 있다. 이 표시는 독립 운영체제나 보안 샌드박스 안에 있다는 뜻이 아니다.
• 현재 실행기 대조터미널과 편집기·Notebook에서 sys.executable을 비교하면 실제로 어느 Python이 코드를 실행하는지 알 수 있다. 패키지를 재설치하기 전에 이 경계를 확인한다.
• 재현 자료환경 이름만 남기기보다 Python·패키지 버전과 채널·플랫폼 조건을 기록한다. 정확한 빌드 조합을 보존하는 파일과 다른 OS로 옮길 요구 목록은 목적이 다르다.

conda env list
python -c "import sys; print(sys.executable)"
python -m pip --version

조회용 교육 예시. 이 페이지를 작성하면서 실행하지 않았으며 conda와 해당 환경의 Python이 설치되어 있다고 가정한다.

10변경 전후 확인

• 의존성업데이트에는 파일 교체뿐 아니라 설정 형식 변화, 의존성 변경, 서비스 재시작이 따를 수 있다.
• 변경 대상과 영향 범위변경 대상과 영향 범위를 확인하고 필요한 경우 이전 상태로 돌아갈 절차를 준비한다.

  • 설치 성공 메시지는 서비스 정상 동작 검증을 대신하지 않는다.

cat /etc/os-release
uname -m
command -v python3
python3 --version

배포판·아키텍처·현재 선택된 Python 실행 환경을 조회한다.

11패키지가 설치되기까지의 단계

• 패키지·저장소패키지 관리자는 저장소의 이름·버전·의존성 같은 메타데이터와 현재 설치 상태를 비교한다.
• 의존성설치나 업그레이드 요청에서는 필요한 의존성을 계산하고 거래 단위의 변경 목록을 만든다.
• 검증·설치 정보 갱신패키지 파일을 받아 출처·무결성 검증을 거친 뒤 파일과 패키지 데이터베이스를 갱신한다.
• 설치 후 처리패키지에 포함된 설치 후 처리도 실행될 수 있으므로 이는 파일 압축을 푸는 것보다 넓은 변경이다.

  • 구체적인 순서와 보증은 도구와 패키지 형식에 따라 다르다.
• 저장소저장소 목록을 갱신하는 단계는 설치 후보에 대한 정보를 새로 읽는 것이다.

  • 설치된 프로그램의 실행 파일을 교체하는 단계와 구분해야 한다.
• 교체 후 남은 프로세스또한 디스크의 실행 파일이 교체돼도 이미 떠 있는 프로세스가 같은 코드나 라이브러리를 계속 사용하고 있을 수 있다.
• 배포판업데이트 완료 이후 서비스 재시작 또는 시스템 재부팅 필요 여부를 배포판 안내와 도구의 진단으로 확인한다.

  • 단순히 버전 출력 한 번으로 모든 실행 중 구성 요소의 상태를 설명할 수는 없다.

1. 후보 조회현재 저장소 정보로 제공 버전을 확인한다.
2. 의존성 계산요청 패키지뿐 아니라 함께 바뀔 항목을 검토한다.
3. 검증 후 설치정책에 맞는 패키지를 설치 상태에 반영한다.
4. 실행 반영 확인새 파일과 현재 실행 중인 프로그램이 같은 상태인지 확인한다.

12설치됐는데 명령 결과가 다른 이유

• 실행 파일 선택command -v 같은 조회로 현재 셸이 선택한 경로를 먼저 확인한다.
• PATHPATH 앞쪽의 가상환경이나 사용자 설치 경로가 배포판 패키지보다 먼저 선택될 수 있고, 같은 이름의 별칭·함수도 영향을 준다.
• 패키지패키지 관리자가 보고한 파일의 소유 패키지와 현재 실행 경로를 연결하면 설치 상태와 사용 상태를 구별할 수 있다.
• 실행 환경의 차이다른 셸·서비스·예약 작업은 환경 변수가 다르므로 터미널에서의 성공만으로 자동 실행 환경을 검증하지 않는다.
• 배포판·패키지문제 재현에는 배포판, 아키텍처, 패키지 출처, 버전, 가상환경과 실행 경로를 함께 기록한다.
• 의존성의존성 충돌에서는 특정 라이브러리만 임의 덮어쓰거나 시스템 Python을 교체하기보다 어떤 프로그램이 어떤 버전을 요구하는지 먼저 확인한다.
• 배포판보안 수정은 배포판이 기존 버전에 역이식할 수 있으므로 상위 프로젝트의 버전 숫자만으로 취약 여부를 단정하지 않는다.
• 변경 목록과 서비스 응답변경 목록과 서비스 응답을 비교해야 업데이트로 해결된 문제와 새로 생긴 문제를 분리할 수 있다.