From aaf44821dbd052dd5c24109e1713ee06b011ef53 Mon Sep 17 00:00:00 2001
From: happybell80 <happybell80@naver.com>
Date: Mon, 9 Mar 2026 17:38:06 +0900
Subject: [PATCH] docs: record current 51124 ssh access

---
 ...�트워크대역오류_python3apt복구.md | 156 ++++++++++++++++++
 1 file changed, 156 insertions(+)
 create mode 100644 journey/troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md

diff --git a/journey/troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md b/journey/troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md
new file mode 100644
index 0000000..3235a62
--- /dev/null
+++ b/journey/troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md
@@ -0,0 +1,156 @@
+---
+tags: [infra, 24-server, ubuntu, gnome-terminal, network, python, apt, troubleshooting]
+---
+
+# 24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+- 공통 작성 원칙: `/home/admin/0_VALUE/02_Governance/writing-principles.md`
+
+## 관련 문서
+- [Infra Journey](../README.md)
+- [23서버 워크스페이스-인프라 구조정리 이슈](./260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
+
+## 사건 요약
+- 24 서버에서 GUI 터미널이 열리지 않아 `Ctrl + Alt + F3`로 텍스트 콘솔(TTY, 그래픽 없이 명령만 입력하는 콘솔)로 진입해 복구를 시작했다.
+- 초반에는 `apt update`가 실패해 패키지 문제처럼 보였지만, 실제 선행 원인은 잘못된 IP 대역 유지였다.
+- 네트워크 복구 후에는 `ModuleNotFoundError: No module named 'apt_pkg'`가 남았고, 이는 Ubuntu 22.04 시스템 Python 기준이 `3.10`이어야 하는데 `python3` 기본 링크가 `3.13`으로 바뀐 상태와 연결됐다.
+
+## 증상
+- GUI 터미널 실행 불가
+- `apt update` 실패
+- 이름 해석 실패 메시지 관측
+- `ping 8.8.8.8` 이전 단계에서 게이트웨이 도달 실패
+- 네트워크 복구 후 `ModuleNotFoundError: No module named 'apt_pkg'` 발생
+
+## 확인된 사실
+### 1. 네트워크
+- 24 서버에는 기존 고정 IP `192.168.219.52`가 남아 있었다.
+- 실제 운영 LAN 대역은 다른 장치 기준 `192.168.0.x`였다.
+- `sudo dhclient -v eno1` 실행 후 `192.168.0.106`을 새로 받아 인터넷 연결이 살아났다.
+- 이후 인터페이스에 `192.168.219.52`와 `192.168.0.106`이 동시에 붙어 있어, 이전 고정 IP가 잔존한 상태로 확인됐다.
+- `ping 8.8.8.8` 성공으로 DNS 이전 단계의 외부 연결은 복구된 것으로 판단했다.
+
+### 2. Python / apt
+- 네트워크 복구 뒤에도 `apt`가 `apt_pkg` 모듈을 찾지 못했다.
+- `python3 --version` 확인 결과 24 서버의 기본 `python3`가 `3.13.5`였다.
+- Ubuntu 22.04 계열의 `python3-apt`는 `Python 3.10 ABI`(Application Binary Interface, 파이썬 확장 모듈이 맞춰져야 하는 바이너리 규격)를 기준으로 제공된다.
+- 따라서 `python3 -> 3.13` 상태에서는 `python3-apt`가 설치돼 있어도 `apt_pkg`를 불러오지 못할 수 있다.
+
+### 3. 최종 복구 방향
+- 시스템 Python 기준을 `3.10`으로 되돌리고,
+- `python3-apt`를 다시 설치한 뒤,
+- `apt update`가 정상 완료되는 것을 확인하는 순서가 맞았다.
+
+## 원인 정리
+### 직접 원인
+- 24 서버 NIC(Network Interface Card, 네트워크 인터페이스) `eno1`에 현재 LAN과 맞지 않는 과거 대역 `192.168.219.52/24`가 남아 있었다.
+- Ubuntu 시스템 Python 링크가 `3.13`으로 바뀌어 `apt`의 Python 바인딩이 깨졌다.
+
+### 근본 원인
+- 네트워크 기준값과 실제 연결된 LAN 대역이 어긋난 채 고정 IP 흔적이 남아 있었다.
+- 개발용 Python 3.13을 시스템 Python 자리에 올려 Ubuntu 22.04의 기본 패키지 체인과 분리되지 않았다.
+
+## 실제 복구 순서
+### 1. 네트워크 복구
+```bash
+sudo dhclient -v eno1
+sudo ip addr del 192.168.219.52/24 dev eno1
+```
+
+### 2. 시스템 Python 기준 복구
+```bash
+sudo ln -sf /usr/bin/python3.10 /usr/bin/python3
+sudo apt install --reinstall python3-apt -y
+```
+
+필요 시 선행 복구 명령:
+
+```bash
+sudo apt install python3.10 python3.10-minimal python3.10-distutils -y
+```
+
+### 3. 패키지 갱신 확인
+```bash
+sudo apt update
+sudo apt upgrade -y
+```
+
+## Python 관련 핵심 해설
+- Ubuntu 22.04는 시스템 도구 다수가 `python3.10` 기준으로 패키징돼 있다.
+- 여기에는 `apt`, `software-properties`, 일부 배포 관리 유틸리티가 포함된다.
+- 따라서 `python3` 기본 링크를 `3.13`으로 바꾸면 개발 환경은 편할 수 있어도 시스템 패키지 관리 체인이 깨질 수 있다.
+- Python 3.13이 필요하면 시스템 링크를 바꾸지 말고 아래 방식 중 하나로 분리해야 한다.
+
+```bash
+/usr/bin/python3.13
+python3.13 -m venv .venv
+```
+
+- 즉 24 서버 문제의 핵심은 "Python 3.13 설치" 자체가 아니라 "Ubuntu 시스템 python3를 3.13으로 교체한 것"이었다.
+
+## 검증 결과
+### 24 서버
+- DHCP로 `192.168.0.x` 대역 IP를 다시 받았다.
+- 2026-03-09 현재 SSH 접속 기준은 `ssh -p 51124 -i ~/.ssh/id_rsa_51123_to_51124 admin@192.168.0.106`이다.
+- 외부 IP `8.8.8.8` 대상 ping 성공이 확인됐다.
+- `apt update`가 최종적으로 정상 동작하는 상태까지 복구됐다.
+- 복구 완료 시점에 `233 packages can be upgraded` 메시지가 관측돼 패키지 목록 로드가 정상화된 것으로 판단했다.
+- 23 서버에서 위 SSH 명령으로 실제 접속 검증 시 `hostname=robeing-i9`, `user=admin` 응답을 확인했다.
+
+### 23 서버 현재 점검 범위
+- 본 문서는 2026-03-09 현재 작업 환경에서 23 서버로 사용 중인 호스트를 기준으로 확인했다.
+- 확인 결과:
+  - `hostname`: `robeing-brains`
+  - `Ubuntu`: `22.04.5 LTS`
+  - `kernel`: `6.8.0-101-generic`
+  - 물리 NIC: `enp6s0`, 주소 `192.168.0.100/24`
+  - 기본 게이트웨이: `192.168.0.1`
+  - `uptime`: `2 days, 18:36`
+  - 루트 디스크 사용률: `38%` (`/dev/sda2`, `81G/228G`)
+  - 메모리: `29Gi` 중 `7.0Gi` 사용, `21Gi` available
+  - `python3 --version`: `Python 3.10.12`
+  - `/usr/bin/python3 -> /usr/bin/python3.10`
+  - `/usr/lib/python3/dist-packages/apt_pkg.cpython-310-x86_64-linux-gnu.so` 존재
+  - `python3 -c 'import apt_pkg'` 성공
+  - `apt-cache policy python3 python3-apt` 기준 설치 상태 정상
+  - `ping -c 2 8.8.8.8` 성공
+  - `ping -c 2 git.ro-being.com` 성공, `106.254.1.37` 해석 확인
+  - `git -C /home/admin/infra/DOCS pull --ff-only`: `Already up to date.`
+  - `sudo apt update` 성공, 업그레이드 가능 패키지 `2개` 확인
+- 따라서 23 서버에서는 이번 24 서버와 동일한 `python3 -> 3.13` 치환 및 `apt_pkg` 손상 징후가 없고, 네트워크/DNS/Git/apt 기본 동작도 현재 시점에 정상으로 확인됐다.
+
+### 23 서버 추가 발견 이슈와 조치
+- 다만 전체 `systemd` 상태 확인에서 `systemctl is-system-running` 결과가 처음에는 `degraded`였다.
+- 실패 유닛은 `logrotate.service` 1건이었고, 원인은 `/etc/logrotate.d/nginx.backup.20251021`가 `/etc/logrotate.d/nginx`와 동일한 `/var/log/nginx/*.log` 항목을 중복 선언한 것이었다.
+- 백업 파일을 아래처럼 `.bak`로 변경해 `logrotate` 대상에서 제외했다.
+
+```bash
+sudo mv /etc/logrotate.d/nginx.backup.20251021 /etc/logrotate.d/nginx.backup.20251021.bak
+sudo systemctl start logrotate.service
+sudo systemctl reset-failed
+```
+
+- 이후 `sudo logrotate -d /etc/logrotate.conf`에서 `Ignoring nginx.backup.20251021.bak, because of *.bak pattern match`를 확인했다.
+- `sudo systemctl status logrotate.service`는 `status=0/SUCCESS`로 종료됐고, `systemctl --failed`는 `0 loaded units listed.`, `sudo systemctl is-system-running`은 `running`으로 복귀했다.
+
+## 재발 방지
+- 24 서버에서 시스템 `python3` 링크를 변경하지 않는다.
+- 개발용 Python 3.13은 `venv` 또는 명시적 바이너리 경로로만 사용한다.
+- 고정 IP를 운용할 때는 현재 LAN 대역과 SSOT를 먼저 대조하고, 과거 대역의 잔존 주소를 제거한다.
+- GUI 터미널 불가 시에는 바로 재설치부터 하지 말고 `TTY 진입 -> 네트워크 확인 -> 시스템 Python 확인 -> apt 복구` 순서로 본다.
+- 23 서버에서는 `/etc/logrotate.d/` 아래에 운영 중인 설정의 백업 파일을 같은 확장자 없이 남기지 않는다.
+
+## 후속 권장 작업
+- 24 서버의 네트워크 설정 파일에서 `192.168.219.52/24`가 다시 붙지 않도록 영구 설정 위치를 확인한다.
+- 24 서버에서 Python 3.13이 필요한 프로젝트가 있으면 시스템 링크 변경 없이 가상환경으로 분리한다.
+- 23/24 공통 운영 기준 문서에 "Ubuntu 22.04 시스템 Python 변경 금지"를 반복 규칙으로 승격할지 검토한다.
+- 23 서버의 남은 패키지 업데이트 `2건`(`network-manager-openvpn`, `network-manager-openvpn-gnome`)은 영향 시간대 확인 후 반영 여부를 결정한다.
+
+## 상위 원칙/근거 문서 연결
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)