응답 헤더의 Server: Apache-Coyote/1.1 은 Apache HTTP Server 가 아니라 Tomcat 의 HTTP 커넥터다. 이름 때문에 httpd 쪽 설정을 뒤지다 시간을 버리기 쉽다.
세션 쿠키 이름도 단서가 된다. JSESSIONID 는 서블릿 컨테이너 일반이고, RANGERADMINSESSIONID 처럼 애플리케이션 고유 이름이 붙어 있으면 그 애플리케이션이 임베디드 Tomcat 위에서 돌고 있다는 뜻이다.
$CATALINA_HOME/webapps/ROOT/<파일명>.jsp
$CATALINA_HOME/webapps/<컨텍스트명>/<파일명>.jsp
URL 이 http://<host>:<port>/etl_info_download.jsp 처럼 컨텍스트 경로 없이 바로 파일명이면 ROOT 컨텍스트다. webapps/ROOT/ 를 먼저 본다.
Referer 헤더도 쓸모가 있다. 같은 화면에서 넘어온 다른 JSP 가 보이면 둘은 대체로 같은 디렉터리에 있다.
find "$CATALINA_HOME/webapps" -name 'etl_info_download.jsp'
WAR 는 기동 시 같은 이름의 디렉터리로 풀린다. 원본 WAR 도 같은 자리에 남아 있다.
ls -l "$CATALINA_HOME/webapps/"*.war
jar -tf "$CATALINA_HOME/webapps/<앱>.war" | grep etl
디렉터리에서 JSP 를 고쳐도 다음 배포 때 WAR 로 덮여 되돌아간다. 고쳐야 한다면 WAR 쪽이 정본이다.
JSP 는 서블릿 소스로 변환된 뒤 컴파일된다.
$CATALINA_HOME/work/Catalina/localhost/<컨텍스트>/org/apache/jsp/<파일명>_jsp.java
$CATALINA_HOME/work/Catalina/localhost/<컨텍스트>/org/apache/jsp/<파일명>_jsp.class
여기 .java 가 있으면 최소한 한 번은 요청이 들어와 컴파일까지 갔다는 뜻이다. JSP 자체가 없어서 나는 문제가 아니라는 근거가 된다.
Hadoop 배포판의 관리 콘솔에서 확인할 수 있다. Ambari 라면 다음을 본다.
| 확인할 것 | 위치 |
|---|---|
| 서비스 포트 | Services → 해당 서비스 → Configs → *-site 의 포트 항목 |
| 외부 URL | Configs 의 externalurl 계열 항목 |
| 설치 호스트 | Hosts → 대상 호스트 → 컴포넌트 목록 |
Ranger Admin 을 예로 들면 ranger.service.http.port 가 6080, ranger.externalurl 이 외부 노출 주소다. Cloudera Manager 를 쓰는 환경이면 같은 정보가 서비스별 구성 화면에 있다.
프로세스에서 직접 찾는 방법도 있다.
ps -ef | grep -i catalina | tr ' ' '\n' | grep -E 'catalina.home|catalina.base'
브라우저의 ERR_INVALID_RESPONSE 는 "파일이 없다" 가 아니다. 서버가 응답을 보내기는 했는데 브라우저가 해석하지 못했다는 뜻이다. JSP 가 없으면 404 가 온다.
원인은 대체로 다음 넷이다.
Content-Length 를 먼저 쓰고 나서 실제 본문이 그보다 짧거나 길면 이렇게 된다.마지막 항목의 흔한 사례가 HTTP 응답에 Strict-Transport-Security 가 들어 있는 경우다 (확인 필요 — 브라우저와 버전에 따라 동작이 다르다). HSTS 는 HTTPS 응답에서만 유효하고 평문 HTTP 응답에서는 무시되는 것이 표준 동작이지만, 이미 HSTS 가 등록된 호스트라면 브라우저가 해당 호스트의 평문 접속 자체를 HTTPS 로 바꿔 시도한다. 그 결과 평문 포트에 TLS 핸드셰이크를 보내게 되고, 돌아온 평문 응답을 해석하지 못해 오류가 난다.
브라우저를 배제하고 확인하면 어느 쪽인지 바로 갈린다.
curl -sv "http://<host>:<port>/etl_info_download.jsp" -o /dev/null
curl 로는 정상인데 브라우저만 실패하면 브라우저 쪽(HSTS · 확장 · 캐시) 문제다. curl 도 응답이 끊기면 서버 쪽이다.
tail -n 200 "$CATALINA_HOME/logs/catalina.out"
tail -n 200 "$CATALINA_HOME/logs/localhost.$(date +%F).log"
tail -n 200 "$CATALINA_HOME/logs/localhost_access_log.$(date +%F).txt"
접근 로그에 요청이 200 으로 기록되어 있는데 브라우저가 실패하면 응답 내용이나 헤더 문제다. 500 이면 localhost.<날짜>.log 에 스택 트레이스가 있다. 요청 자체가 없으면 앞단 프록시나 방화벽에서 끊긴 것이다.