open_basedir 제한 환경에서 dashboard API HTTP 500 대응 체크리스트

open_basedir 제한 환경에서 관리자 dashboard API가 HTTP 500으로 중단되는 문제를 확인한 뒤, 현재 운영 중 정리한 대응 체크리스트와 구조 방향입니다. 초기 문제는 dashboard 내부 시스템 리소스 probe 과정에서 발생했습니다. 예를 들어: - /proc/meminfo 접근 - disk_total_space() - disk_free_space() - file_exists() 등 Linux 시스템 자원 확인 로직이 제한 환경에서 warning을 발생시키고, Laravel이 이를 ErrorException으로 승격하면서 API 전체 실패로 이어지고 있었습니다. 특히 다음 환경에서는 동일 문제가 재현될 가능성이 있었습니다. - open_basedir 활성화 - shared hosting - hardened PHP-FPM - container/chroot - restricted filesystem - /proc 접근 제한 현재 운영 기준에서는: "시스템 리소스 측정 실패" 와 "dashboard API 실패" 를 분리하는 방향이 더 안정적이라고 판단했습니다. 현재 정리 중인 대응 방향은 다음과 같습니다. 1. filesystem 접근 runtime-safe 처리 다음 함수들은 제한 환경에서 실패 가능성이 있기 때문에: - file_exists() - is_readable() - file_get_contents() - disk_total_space() - disk_free_space() - shell_exec() 직접 호출보다: - safe wrapper - guarded probe - helper abstraction 형태로 보호. 특히 warning → ErrorException 전파를 차단하는 방향을 우선 검토 중입니다. 2. resource probe 실패와 API 실패 분리 현재는: resource probe 실패 → dashboard API 전체 실패 형태에 가까웠는데, 운영 환경에서는 dashboard resource 정보가 부가 상태 정보에 가까운 만큼: resource probe 실패 → fallback 값 반환 → dashboard API는 정상 응답 유지 구조가 더 안정적이라고 판단했습니다. 예: { "cpu": { "percentage": 0 }, "memory": { "percentage": 0, "used": "0 B", "total": "0 B" }, "disk": { "percentage": 0, "used": "0 B", "total": "0 B" } } 또는 unknown 상태 반환. 3. runtime condition 기반 설계 현재는 운영 환경 차이를: - 예외 상황 - 특수 케이스 가 아니라, "예상 가능한 runtime condition" 으로 다루는 방향을 중요하게 보고 있습니다. 특히: - shared hosting - restricted filesystem - container/chroot - hardened PHP-FPM - open_basedir 같은 환경은 실제 운영 환경에서 충분히 발생 가능한 조건이라고 판단했습니다. 4. dashboard UI 안정성 우선 현재 dashboard는 상태 표시 UI 성격이 강하기 때문에, 일부 시스템 정보를 읽지 못하더라도: - 관리자 화면 유지 - API response shape 유지 - HTTP 200 유지 방향이 운영 안정성 측면에서 더 적절하다고 보고 있습니다. 5. 추가 확인 중인 항목 현재 추가로 다음 부분도 계속 확인 중입니다. - disabled shell_exec 환경 - filesystem permission 제한 - WAN 분리 환경 - queue worker 제한 환경 - restricted PHP-FPM runtime - fallback serialization consistency 현재는 dashboard probe 실패가 운영 전체 실패로 이어지지 않도록 runtime-safe 방향으로 계속 구조를 정리 중입니다.