2026-09-08 (화) 개발일지
Logpresso 문서 탐색과 시스템 환경 구성 — 404와 요구사항 불일치를 잡은 하루
오늘은 Logpresso Sonar 5.0 프로젝트의 문서 기반을 정리하면서, 공식 문서 링크가 404로 떨어지는 문제, Sonar 4.0의 요구사항이 노션 기록과 다른 점, 그리고 SSH 접속 사전 검증 로직의 정확한 조건을 확인했다. 세 가지 모두 처음엔 단순 실수나 오타라 생각했는데, 파고들수록 문서 구조와 환경 구성의 미묘한 차이가 드러났다.
Rockylinux ISO 다운로드 경로 — pub 대신 vault를 써야 하는 이유
프로젝트 README에 ISO 다운로드 경로가 미확정으로 남아 있었다. Proxmox NFS 스토리지에 올릴 Rocky Linux ISO를 어디서 받을지 결정해야 했다. 공식 사이트에서 rockylinux.org/pub/ 경로를 먼저 찔러봤다. HTTP 404가 떨어졌다. ‘링크가 깨졌나?’ 싶어 curl -I로 몇 가지 변형을 시도했지만, pub 디렉토리 자체가 존재하지 않았다.
처음엔 단순한 URL 오타라 생각했다. 버전 태그가 잘못되었거나, 최신 ISO가 다른 곳으로 이동했을 거라고 추정했다. 하지만 Rockylinux 공식 다운로드 페이지를 확인해보니, 구버전 ISO는 전부 vault 디렉토리로 옮겨져 있었다. 현재 안정 버전만 pub에 있고, 10.0은 이미 vault로 이관된 상태였다.
핵심 발견: Rockylinux 10.0 ISO는
dl.rockylinux.org/vault/rocky/10.0/isos/x86_64/에만 존재한다.pub은 404.
해결은 간단했다. README에 명시된 경로를 vault 기반으로 바꾸고, Proxmox NFS 스토리지(/mnt/pve/nas-hdd/template/iso/)에 ISO를 내려받았다. NFS라 한 노드에서만 받으면 4개 노드가 공유하므로, 한 번의 wget으로 끝났다. storage.cfg의 content 줄에 iso가 포함되어 있는지도 확인했다.
검증: pvesh get /storage/nas-hdd/content 명령으로 ISO 파일이 정상 등록됨을 확인했다. 이후 템플릿 생성도 문제없었다.
Sonar 4.0 요구사항 — 노션 기록과 공식 문서의 괴리
프로젝트 노션에는 jdk-11.0.14.1이 명시되어 있었다. 그런데 Logpresso 공식 문서를 읽다 보니, Sonar 5.0이 OpenJDK 21, RHEL 9, MariaDB 11.8을 요구한다는 내용이 있었다. ‘4.0은 다르겠지’ 싶어 Sonar 4.0 문서도 직접 확인했다. 결과는 동일했다. 4.0 역시 OpenJDK 21, RHEL 9를 요구하고 있었다.
이게 말이 되나? 실제 납품 환경은 RHEL 8 계열이 대부분인데. 첫 가설은 ‘문서가 최신 버전 기준으로 덮어씌워진 것’이었다. 4.0 문서가 5.0과 동일한 페이지를 공유하거나, 버전 선택기가 꼬였을 거라 생각했다. 하지만 URL을 직접 살펴보니 .../sonar/4.0/ui/ 경로가 정확히 4.0을 가리키고 있었다. 스크린샷까지 4.0 UI였다.
그제서야 진짜 원인을 의심하게 됐다. el8에 OpenJDK 21이 있는가? RHEL 8의 기본 JDK는 11이다. 하지만 EPEL이나 AppStream을 통해 21을 설치할 수 있는지 확인했다. 공식 문서의 요구사항 페이지를 다시 정독하니, OpenJDK 21은 el9 기반으로 명시되어 있었다. 결국 RHEL 8에서는 공식적으로 지원되지 않는 환경이었다.
해결은 프로젝트 요구사항 재정의였다. 노션의 JDK 11 기록은 구버전 Sonar(3.x) 기준이거나, 잘못된 정보였다. Sonar 4.0/5.0 모두 OpenJDK 21 + RHEL 9가 정확한 요구사항이며, el8 환경은 별도로 테스트가 필요하다는 결론을 README에 추가했다.
검증: Logpresso 공식 docs 페이지를 3회 재확인 (4.0 UI 가이드, 설치 가이드, 릴리스 노트). 모두 동일한 요구사항을 명시하고 있었다.
SSH 접속 사전 검증 — preflight.py가 차단하는 4가지 조건
프로젝트 초기화 스크립트(preflight.py)가 SSH 연결을 테스트하는 과정에서, 특정 노드에서 BLOCK 메시지와 함께 전체 진행이 멈추는 현상이 발생했다. 처음엔 방화벽 문제라 생각했다. nc -zv로 22번 포트를 찔러보니 응답이 정상이었다. ‘그럼 방화벽은 통과인데?’ 다른 노드에서는 잘 되는 걸 보니, 환경 차이 때문일 거라 추정했다.
코드를 직접 열어봤다. preflight.py:56-61을 보니, Node.run과 Node.sudo로 각 노드에 echo __ok__와 sudo id -u를 던지고, 응답이 없으면 즉시 BLOCK을 띄우고 시스템을 중단시키는 구조였다. 즉, 4가지 조건이 모두 충족되어야 했다:
- sshd 기동
- sudo 계정 존재
- 22번 포트 도달 가능
- 고정 IP 할당
방화벽이 열려 있어도, sshd가 안 뜨거나 sudo 권한이 없으면 BLOCK이었다. 문제의 노드는 sshd가 실행 중이었지만, sudo 명령어가 requiretty 설정 때문에 비대화형 세션에서 실패하고 있었다. sudoers에 Defaults !requiretty를 추가해 해결했다.
검증: 해당 노드에서 ssh user@host 'sudo id -u'로 직접 테스트 후, preflight.py 재실행하여 정상 통과를 확인했다.
오늘의 한줄
공식 문서와 실제 환경, 그리고 코드가 말하는 조건 사이의 간극은 항상 존재하지만, 직접 찔러보고 코드를 읽지 않으면 절대 드러나지 않는다.