diff --git a/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md b/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md index 69241bf..70cbdad 100644 --- a/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md +++ b/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md @@ -1,117 +1,7 @@ -# 250731 로그 저장소 SSHFS 설정과 템플릿 해결책 +# 250731_로그저장소_SSHFS설정과_템플릿해결책 -## 문제 상황 +이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다. -### 초기 문제 -- rb10508 등 로빙 컨테이너들의 로그가 SSD에 저장되고 있음 -- CLAUDE.md에 명시된 대로 로그는 HDD(/mnt/hdd/logs/)에 저장되어야 함 -- 51123 서버에 HDD가 있고, 51124 서버에서 접근 필요 - -### SSHFS가 적합한 이유 -1. 이미 SSH 키 설정 완료 - 추가 인증 설정 불필요 -2. 다양한 로그 형태 지원 - stdout/stderr뿐만 아니라 파일 로그도 저장 -3. 설정 최소화 - 51123 서버는 디렉토리만 만들면 됨 -4. 투명한 작동 - 컨테이너는 로컬 디렉토리처럼 사용 - -## 실제 설정 과정 - -### 오후 10시 48분 - 51123 서버 작업 -```bash -# 1. 51124서버 전용 로그 디렉토리 생성 -sudo mkdir -p /mnt/hdd/logs/51124-server -sudo chown admin:admin /mnt/hdd/logs/51124-server - -# 2. 51124서버의 SSH 공개키 추가 -# 51124 서버의 ~/.ssh/id_rsa_deploy.pub 내용을 ~/.ssh/authorized_keys에 추가 - -# 3. cleanup 스크립트에 51124 서버 로그 정리 추가 -# 51124 서버 로그도 30일 후 자동 정리되도록 설정 -``` - -### 오후 10시 50분 - 51124 서버 작업 -```bash -# 1. SSHFS 설치 -sudo apt install -y sshfs - -# 2. 마운트 포인트 생성 -sudo mkdir -p /mnt/51123logs - -# 3. 마운트 시도 (초기 실패 - SSH 키 문제) -sudo sshfs -o allow_other,reconnect admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123 -``` - -### 오후 10시 51분 - SSHFS 마운트 성공 -```bash -# 1. SSH 키 파일 지정하여 마운트 -sshfs -o IdentityFile=/home/admin/.ssh/id_rsa_deploy admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123 - -# 2. 마운트 확인 -df -h /mnt/51123logs -# 결과: 916G 크기의 HDD가 성공적으로 마운트됨 - -# 3. 테스트 -mkdir -p /mnt/51123logs/rb10508 -echo "SSHFS mount test - $(date)" > /mnt/51123logs/rb10508/test.log -``` - -## 권한 문제의 딜레마 - -### 발견된 문제점 -1. **SSHFS 마운트**: admin(UID 1000)으로 마운트됨 -2. **Docker 컨테이너**: UID 999로 실행 -3. **권한 불일치**: Docker가 디렉토리 생성 시 실패 - -### 검토한 해결방안들 - -#### 1. 심볼릭 링크 -```bash -ln -s /mnt/51123logs/rb10508 logs -``` -- 간단하지만 로빙마다 수동 작업 필요 - -#### 2. docker-compose.yml 직접 수정 -```yaml -volumes: - - /mnt/51123logs/rb10508:/code/logs:rw -``` -- 명확하지만 역시 로빙마다 수정 필요 - -#### 3. SSHFS UID 매핑 -```bash -sudo sshfs -o allow_other,uid=999,gid=999 ... -``` -- root 권한 필요, 복잡함 - -#### 4. 사전 권한 설정 -```bash -sudo chown -R 999:999 /mnt/hdd/logs/51124-server/ -``` -- 여전히 디렉토리는 수동 생성 필요 - -## 제안된 해결책 (미구현) - -**참고**: 이 템플릿 방식은 제안만 되었고, 실제로는 250801 크론잡 방식으로 해결됨. -- 크론잡으로 매일 새벽 3시 rsync 동기화 -- 자세한 내용은 [250801_claude_크론잡로그동기화설정.md](./250801_claude_크론잡로그동기화설정.md) 참조 - -## 교훈 -1. **서버 간 통신은 항상 SSH 키 먼저**: 51123-51124 간 SSH 키가 설정되어 있지 않았음 -2. **마운트 포인트 이름 규칙**: /mnt/51123logs처럼 연결하는 서버 번호를 명시하면 관리가 편함 -3. **SSHFS vs NFS**: 간단한 로그 저장용도는 SSHFS가 설정이 훨씬 간편함 -4. **SSH 키 파일 명시**: -o IdentityFile 옵션으로 특정 키 파일 지정 필요 -5. **처음부터 템플릿 설계**: 하드코딩은 나중에 고통 -6. **권한 문제는 미리 해결**: Docker UID/GID 차이 주의 -7. **자동화는 필수**: 수동 작업은 실수의 원인 - -## 실제 구현 상태 -- **250801 크론잡 방식으로 구현 완료** -- 매일 새벽 3시 자동 동기화 중 -- 7일 이상 로컬 로그 자동 삭제 - ---- - -작성일: 2025-07-31 -작성자: Claude (51123 서버 - SSH 키 등록 및 디렉토리 생성) - Claude (51124 서버 - SSHFS 설정 및 마운트) - 로컬 개발자 (템플릿 해결책 제안) -주제: 로그 저장소 중앙화를 위한 SSHFS 설정과 템플릿 기반 자동화 \ No newline at end of file +- 새 위치: `250731_로그저장소_SSHFS설정과_템플릿해결책.md` +- 인프라 기준 문서: +- 이유: 23/24 서버 간 로그 저장소 마운트, SSHFS, 권한 매핑, HDD 로그 보존 구조를 공통 인프라 기준으로 다루기 때문입니다. diff --git a/journey/troubleshooting/250930_opensearch_hdd_migration.md b/journey/troubleshooting/250930_opensearch_hdd_migration.md index 4859910..fb900c9 100644 --- a/journey/troubleshooting/250930_opensearch_hdd_migration.md +++ b/journey/troubleshooting/250930_opensearch_hdd_migration.md @@ -1,62 +1,7 @@ -# OpenSearch HDD 마이그레이션 +# 250930_opensearch_hdd_migration -## 문제 -- OpenSearch 데이터가 SSD(/var/lib/opensearch)에 저장 -- SSD 용량 부족 우려 +이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다. -## 해결 - -### 1. 데이터 마이그레이션 -```bash -sudo mkdir -p /mnt/hdd/opensearch -sudo cp -rp /var/lib/opensearch/* /mnt/hdd/opensearch/ -sudo chown -R 1000:1000 /mnt/hdd/opensearch -``` - -### 2. 설정 파일 변경 - -**파일**: `/home/admin/opensearch/docker-compose.yaml` -- 34번 라인: `/var/lib/opensearch` → `/mnt/hdd/opensearch` - -**파일**: `/home/admin/opensearch/.gitea/workflows/cicd.yml` -- 17-19번 라인: `/var/lib/opensearch` → `/mnt/hdd/opensearch` -- 30-31번 라인: 기존 컨테이너 중복 방지 코드 추가 - -**파일**: `/home/admin/opensearch/Dockerfile` -- 보안 인증서 COPY 라인 제거 -- `ENV plugins.security.disabled=true` 추가 - -### 3. 보안 플러그인 비활성화 -- docker-compose.yaml 15번 라인: `DISABLE_SECURITY_PLUGIN=true` -- 내부 네트워크 전용 서비스로 TLS 불필요 - -### 4. 해결 과정 중 발생한 문제 -- Actions 실패: TLS 인증서 파일 없음 → 보안 플러그인 비활성화로 해결 -- 컨테이너 이름 충돌 → Actions에 기존 컨테이너 제거 코드 추가 -- 설정 중복 에러 → Dockerfile ENV 제거, docker-compose.yaml에서만 설정 - -### 5. 최종 상태 -- 데이터 경로: `/mnt/hdd/opensearch` (354MB) -- 컨테이너: opensearch (opensearch-opensearch-node 이미지) -- 포트: 9200, 9600 -- HDD 여유 공간: 869GB -- API 응답: 정상 -- 로그 수집: fluent-bit → data-prepper → OpenSearch 정상 - -### 6. 추가 이슈 (2025-09-30) -- **문제**: 9/29부터 로그 수집 중단 -- **증상**: fluent-bit → data-prepper 200 OK, 하지만 OpenSearch 저장 실패 -- **에러**: `Cannot deserialize value of type java.util.ArrayList from Object value` -- **원인**: Data Prepper가 JSON 배열 `[{...}]` 요구, fluent-bit이 단일 객체 `{...}` 전송 -- **시도한 해결책**: - - json_array on 추가 (Fluentd 전용 파라미터, Fluent Bit에는 없음) - - Flush 5초, Grace 30 설정 (배치 처리 시도) - - Format json_lines (Data Prepper 비호환) -- **상태**: 미해결, 추가 조사 필요 - -### 7. 커밋 이력 -- 7466068: HDD 경로 변경 -- 5f7bf49: Actions 워크플로우 경로 수정 -- 2df7afb: 보안 플러그인 비활성화 -- 8f667d3: DISABLE_SECURITY_PLUGIN 환경변수 수정 -- 66b5ee8: Dockerfile 중복 설정 제거 \ No newline at end of file +- 새 위치: `250930_opensearch_hdd_migration.md` +- 인프라 기준 문서: +- 이유: OpenSearch 저장 경로, HDD 마이그레이션, 로그 파이프라인과 스토리지 운영 문제를 공통 인프라 기준으로 다루기 때문입니다. diff --git a/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md b/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md index 2a75b58..96ae1b6 100644 --- a/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md +++ b/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md @@ -1,195 +1,7 @@ -# skill-rag-file SSHFS allow_other 권한 문제 해결 +# 251014_skill-rag-file_sshfs_allow_other_해결 -**날짜**: 2025-10-14 -**작성자**: Claude -**관련 파일**: `skill-rag-file/docker-compose.yml` +이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다. ---- - -## 문제 상황 - -### 증상 -- skill-rag-file 컨테이너가 `/mnt/51123data/documents/`에 파일 저장 -- 컨테이너 내부에서만 파일 보임 -- 호스트와 51123 서버 HDD에는 저장 안됨 -- 컨테이너 재시작 시 파일 손실 - -### 근본 원인 -1. **SSHFS 마운트**: `user_id=1001,group_id=1000` (admin:xusers) -2. **컨테이너 실행**: root (UID 0) -3. **권한 불일치**: FUSE는 기본적으로 마운트한 사용자만 접근 허용 -4. **allow_other 미사용**: 다른 UID 접근 차단 - -### 검증 -```bash -# 컨테이너 내부 -docker exec skill-rag-file ls /mnt/51123data/documents/79441171.../2025-10/ -# → 파일 보임 - -# 호스트 -ls /mnt/51123data/documents/79441171.../2025-10/ -# → No such file or directory -``` - ---- - -## 해결 과정 - -### 1단계: /etc/fuse.conf 수정 - -```bash -sudo sed -i 's/^#user_allow_other/user_allow_other/' /etc/fuse.conf -``` - -**결과**: -``` -user_allow_other -``` - -**의미**: 일반 사용자가 `allow_other` 옵션 사용 가능 - -### 2단계: SSHFS 재마운트 - -```bash -# 기존 마운트 해제 -sudo fusermount -u /mnt/51123data - -# allow_other 옵션 추가하여 재마운트 -sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123 -``` - -**마운트 옵션 확인**: -```bash -mount | grep 51123data -# admin@192.168.219.45:/mnt/hdd/data on /mnt/51123data type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1000,default_permissions,allow_other) -``` - -### 3단계: docker-compose.yml 볼륨 추가 - -**파일**: skill-rag-file/docker-compose.yml - -```yaml -volumes: - - ./chroma_db:/app/chroma_db - - ./logs:/app/logs - - ./.env:/app/.env:ro - - /mnt/51123data:/mnt/51123data:rw # 추가 -``` - -### 4단계: 컨테이너 재시작 - -```bash -cd /home/admin/ivada_project/skill-rag-file -docker compose down -docker compose up -d -``` - -**결과**: 컨테이너 정상 시작 (DOCS/250915 문서의 "mkdir /mnt/51123data: file exists" 에러 발생 안함) - ---- - -## 검증 결과 - -### 테스트 1: 파일 쓰기 -```bash -docker exec skill-rag-file touch /mnt/51123data/documents/test_write_from_container.txt -ls -la /mnt/51123data/documents/ | grep test_write -# -rw-r--r-- 1 admin xusers 0 10월 14 01:01 test_write_from_container.txt -``` - -**결과**: ✅ 컨테이너 → 호스트 즉시 동기화 - -### 테스트 2: 디렉토리 생성 -```bash -docker exec skill-rag-file mkdir -p /mnt/51123data/documents/test_team/2025-10 -docker exec skill-rag-file touch /mnt/51123data/documents/test_team/2025-10/test.pdf -ls -la /mnt/51123data/documents/test_team/2025-10/ -# total 8 -# drwxr-xr-x 1 admin xusers 4096 10월 14 01:01 . -# -rw-r--r-- 1 admin xusers 0 10월 14 01:01 test.pdf -``` - -**결과**: ✅ 디렉토리 생성 및 권한 매핑 정상 - -### 테스트 3: 영속성 -```bash -docker compose down && docker compose up -d -docker exec skill-rag-file ls /mnt/51123data/documents/ | grep test -# test.txt -# test_team -# test_write_from_container.txt -``` - -**결과**: ✅ 재시작 후에도 파일 유지 - ---- - -## 핵심 설정 요약 - -### /etc/fuse.conf -``` -user_allow_other -``` - -### SSHFS 마운트 명령 -```bash -sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123 -``` - -### docker-compose.yml -```yaml -volumes: - - /mnt/51123data:/mnt/51123data:rw -``` - ---- - -## 교훈 - -### FUSE 기본 보안 정책 -- FUSE는 기본적으로 마운트한 사용자만 접근 허용 -- 컨테이너 내부 다른 UID 사용 시 접근 불가 -- `allow_other` 옵션으로 해결 가능 - -### allow_other 사용 조건 -- `/etc/fuse.conf`에 `user_allow_other` 필수 -- `default_permissions` 옵션 권장 (일반 파일시스템 권한 체크) -- 보안 위험: 모든 사용자가 접근 가능하므로 신중히 사용 - -### Docker 볼륨 마운트 -- SSHFS 마운트 포인트를 Docker 볼륨으로 사용 가능 -- `allow_other` 없으면 컨테이너 내부에만 파일 존재 (휘발성) -- 볼륨 마운트 시 `/mnt/51123data:/mnt/51123data:rw` 형태로 전체 마운트 포인트 바인드 - -### 과거 문서 오류 -- DOCS/250915: "볼륨 제거"가 해결책이 아님 → 임시 우회책 -- DOCS/250731: "Docker SSHFS 충돌"로 롤백 → allow_other로 해결 가능 -- 교훈: FUSE 권한 모델 이해 부족으로 잘못된 결론 도출 - ---- - -## 추가 발견 (2025-10-14 23:30) - -### 문제: SSHFS 긴 파일명 처리 실패 - -**증상**: -- coldmail workflow 실행 시 PDF 업로드 500 에러 -- 로그: `OSError: [Errno 74] Bad message` -- 파일명 예시: `1d8072302cf85eee...pdf` (150자 이상) - -**원인**: -- upload.py:82: `f"{file_hash}_{file.filename}"` → 150자 초과 -- SSHFS 파일시스템의 파일명 길이 제한 - -**구현 완료** (커밋 dfe6978): -- ✅ skill-rag-file/app/api/upload.py:73-87,106-107 수정 완료 -- ✅ import uuid 추가 (upload.py:5) -- ✅ coldmail workflow PDF 첨부파일 재테스트 대기 - ---- - -## 관련 문서 - -- 250915_skill-rag-file_Docker_빌드_및_볼륨_마운트_문제.md -- 250915_skill-rag-file_초기_구축.md -- 250731_claude_SSHFS권한문제해결.md +- 새 위치: `251014_skill-rag-file_sshfs_allow_other_해결.md` +- 인프라 기준 문서: +- 이유: SSHFS 마운트, FUSE 권한, 컨테이너 볼륨 경로 정합성을 공통 인프라 기준으로 다루기 때문입니다. diff --git a/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md b/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md index 6101da8..38f4599 100644 --- a/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md +++ b/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md @@ -1,45 +1,7 @@ -# PostgreSQL/Neo4j TCP 소켓 헬스체크 구현 +# 260115_postgresql_neo4j_tcp_healthcheck -**날짜**: 2026-01-15 -**작성자**: Auto -**관련 파일**: -- `admin-dashboard/backend/services/system_service.py:32-33, 346-384, 421-423` +이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다. ---- - -## 문제 상황 - -PostgreSQL/Neo4j가 HTTP 체크로 실패하여 Admin Dashboard에서 오류 표시 (실제로는 정상 작동 중) - ---- - -## 해결 방안 - -- `system_service.py:32-33`: PostgreSQL/Neo4j HTTP URL 제거, `check_method: "tcp"` 추가 -- `system_service.py:346-384`: `check_tcp_service()` 함수 추가, 여러 호스트 시도 (`172.17.0.1` → `localhost` → `127.0.0.1`) -- `system_service.py:421-423`: `check_method == "tcp"`인 경우 TCP 체크로 분기 처리 - ---- - -## 구현 완료 - -- Git 커밋: `4c9f227` -- API 테스트: PostgreSQL/Neo4j 모두 `check_method: "tcp"`, `status: "healthy"` 확인 - ---- - -## 교훈 - -### 데이터베이스 서비스는 TCP 소켓 체크 사용 -- HTTP 프로토콜이 아닌 서비스는 TCP 소켓 체크 필수 -- Docker 컨테이너에서 호스트 접근 시 여러 호스트 시도로 네트워크 격리 문제 완화 - -### 브라우저 테스트 시 docs 확인 필수 -- 로그인 비밀번호, API 엔드포인트 등 접근 정보는 코드 또는 docs에서 확인 (추측 금지) - ---- - -## 참고 - -- `plans/251225_admin_dashboard_navigation_structure_refactoring.md` -- `troubleshooting/251228_admin_서비스_헬스체크_개선.md` +- 새 위치: `260115_postgresql_neo4j_tcp_healthcheck.md` +- 인프라 기준 문서: +- 이유: PostgreSQL, Neo4j 헬스체크 방식과 Docker 컨테이너-호스트 접근 규칙을 공통 인프라 기준으로 다루기 때문입니다. diff --git a/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md b/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md index a479ff2..929309e 100644 --- a/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md +++ b/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md @@ -1,81 +1,7 @@ -tags: [env, secrets, git, security, troubleshooting] +# 260308_env_backup_git_tracking_exposure_및_차단조치 -# 260308 env backup git tracking exposure 및 차단조치 +이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다. -상위 원칙: -- [global-principles](../../../../0_VALUE/00_Principles/global-principles.md) -- [writing-principles](../../../../0_VALUE/02_Governance/writing-principles.md) - -## 1. 목적 -- `rb8001` 저장소에 `.env` 백업본과 배포용 env 파일이 git 원격에 포함된 경위를 기록합니다. -- 동일 유형 파일이 다시 원격에 올라가지 않도록 차단한 조치와 잔여 범위를 남깁니다. - -## 2. Facts - -### 2.1 `rb8001` 노출 사실 -- 대상 파일: `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy` -- 원격 반영 커밋: - - `b9731bfc68bd12d0bdefc74a1403a878433c6824` (`2026-01-02 12:53:52 +0900`): `.env.backup` 추가 - - `5f24b2bdb515b0a372cebaf62052f7086d41e739` (`2026-03-07 17:01:56 +0900`): `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy` 포함 -- `5f24b2b`는 로컬 reflog 기준 같은 시각에 `refs/remotes/origin/main: update by push`가 확인됐습니다. - -### 2.2 `rb8001` 원인성 설정 사실 -- `/home/admin/robeing/rb8001/.gitignore`에는 기존에 `.env`만 있었고 `.env.*`, `*.env.*` 차단 규칙은 없었습니다. -- 저장소 내부 검색 기준, `.env.bak.*` 또는 `.env.backup` 생성을 지시하는 자동 스크립트/코드는 확인되지 않았습니다. -- `/home/admin/AGENTS.md`에는 환경변수 기준을 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`로 두고, 서비스별 `.env`는 임시 로컬 오버라이드 전용이라고 명시돼 있습니다. - -### 2.3 `rb8001` 즉시 조치 사실 -- `2026-03-08`에 `.gitignore`를 아래 패턴까지 확장했습니다. - - `.env.*` - - `*.env` - - `*.env.*` - - 예외: `.env.deploy.example` -- 추적 중이던 `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy`를 git 인덱스에서 제거했습니다. -- 위 변경은 커밋 `5f0087d` (`chore: stop tracking env files`)로 `origin/main`에 push됐습니다. -- 로컬 파일도 `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`를 삭제했습니다. - -### 2.4 워크스페이스 전수 확인 사실 -- 백업본 실파일 확인: - - `/home/admin/robeing/skill-news/.env.backup` -- git 추적 중인 `.env*` 확인: - - `/home/admin/fluent-bit`: `.env` - - `/home/admin/ivada_project/robeing-monitor`: `.env.deploy`, `.env.deploy.example` - - `/home/admin/robeing/robeing-monitor`: `.env.deploy`, `.env.deploy.example` - - `/home/admin/robeing/skill-calendar`: `.env.deploy`, `.env.deploy.example` - - `/home/admin/robeing/skill-email`: `.env.deploy`, `.env.deploy.example` - - `/home/admin/robeing/skill-embedding-repo`: `.env.deploy`, `.env.deploy.example`, `.env.example` - - `/home/admin/robeing/skill-news`: `.env.backup`, `.env.deploy`, `.env.deploy.example`, `.env.example` - - `/home/admin/robeing/skill-rag-file`: `.env.deploy`, `.env.deploy.example`, `.env.example` - - `/home/admin/robeing/skill-slack`: `.env.deploy`, `.env.deploy.example` - - `/home/admin/vMIR/LocalTerra`: `.env` - - `/home/admin/vMIR/mirror-terra-web-dapp-ref`: `.env`, `.env.development` - - `/home/admin/vMIR/vmir-web-app`: `.env`, `.env.development` -- `/home/admin/auth-server`는 `.git/config` 권한 문제로 이번 점검에서 추적 여부를 확정하지 못했습니다. - -## 3. Interpretation -- `rb8001`의 직접 원인은 `.env`만 무시하고 `.env` 파생 파일을 무시하지 않은 `.gitignore` 공백입니다. -- `.env.bak.20260304032910`, `.env.bak.20260306193102`는 파일명과 내용상 `.env`의 시점별 수동 백업본으로 해석됩니다. -- 이 문제는 단일 저장소 실수라기보다, 여러 저장소에서 `.env`, `.env.deploy`, `.env.backup`를 버전 관리 대상으로 다뤄 온 운영 습관 문제로 봐야 합니다. -- 전역 원칙 문서가 요구하는 방향은 SSOT(Single Source of Truth, 단일 진실 공급원) 기반의 `runtime.env`/`secrets.env` 분리이며, 서비스 루트의 실제 비밀 env 파일을 git에 유지하는 방식과 충돌합니다. - -## 4. Unresolved -- 이미 원격 히스토리에 포함된 민감값은 커밋 삭제만으로 무효화되지 않으므로, 실제 키 폐기와 재발급 여부를 별도로 확인해야 합니다. -- `skill-news`를 포함한 다른 저장소들의 `.env*` 추적 해제 범위는 아직 미적용 상태입니다. -- `auth-server`는 권한 문제를 해소한 뒤 `.env*` 추적 여부를 다시 확인해야 합니다. -- `.env.deploy`를 예제 파일만 남기고 모두 제거할지, SSOT 경로 참조 방식으로 전환할지 저장소별 운영 기준 정리가 필요합니다. - -## 5. 다음 조치 후보 -- 우선순위 1: 원격 히스토리에 노출된 Slack, OpenAI, Perplexity, Tavily, JWT 등 민감값 폐기 및 재발급 -- 우선순위 2: `skill-news` 포함 나머지 저장소에도 동일한 `.gitignore` 확장과 git 추적 해제 적용 -- 우선순위 3: 서비스별 `.env.deploy`를 예제 파일만 남기는 구조로 통일하거나, `/home/admin/infra-config` 참조 구조로 일원화 - -## 6. 검증 근거 -- `git log --follow --date=iso --name-status -- .env.bak.20260304032910` -- `git show --stat --summary 5f24b2bdb515b0a372cebaf62052f7086d41e739` -- `git reflog --date=iso --all` -- `git ls-files '.env*'` -- `find /home/admin -path '*/.git' -prune -o -type f \( -name '.env.backup' -o -name '.env.bak.*' -o -name '.env.deploy' -o -name '.env' \) -print` - -관련 문서: -- [260307 gateway SSOT(runtime/secrets) 분리 적용 및 검증](./260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md) -- [README](./README.md) +- 새 위치: `260308_env_backup_git_tracking_exposure_및_차단조치.md` +- 인프라 기준 문서: +- 이유: 서비스별 `.env` 오버라이드, SSOT runtime/secrets, git 추적 노출 문제를 워크스페이스 공통 인프라 기준으로 다루기 때문입니다.