이름을 지운다고 갈리지 않는다

두 사업의 경계를 가르는 작업이 있었다. 한쪽에서 문서의 이름을 전부 지웠다.

Open Table of contents

상황 — 문서에서만 지운 이름

정리된 것은 문서 쪽뿐이었다.

문서에서 흔적 삭제  →  완료
실제 설정 정리      →  "다른 소관"

실물은 손대지 않은 채로 남았다.

A 쪽: 문서에서 지웠으니 우리 일은 끝
B 쪽: 그런 게 있는지 모름
    ↓
어느 작업 목록에도 안 걸린 채 흘러간다

한쪽은 끝냈다고 보고 다른 쪽은 conf.d 에 그런 것이 있는 줄도 모르니 아무도 안 하게 된다.

문서에서 지운 것과 서버에서 사라진 것은 전혀 다른 사건이다. 문서와 nginx 설정이 같은 상태인지 확인한 사람이 없었다.

서버에 들어가 conf.d 를 확인했다.

ls -la /etc/nginx/conf.d/

/etc/nginx/conf.d/ 에 그 조직 도메인용 설정 파일이 그대로 있었다.

문서에는 없는 이름이 conf.d 에는 남아 있는 셈이다. 여기서 멈추면 파일이 있다는 것까지만 알고 그것이 살아 있는지는 모른다.

conf.d 에 파일이 있다고 로드되는 것은 아니라서 그다음을 봤다.

nginx -T | grep -c '<도메인>'
# 5

nginx -T 에 다섯 번 찍혔으니 실제로 읽혀 들어가고 있었다.

listen 80 과 443 에서 그 도메인을 받아 내부로 넘기는 설정이라 죽은 파일이 아니었다.

그 server 블록을 열어 보니 인증서 경로도 있었다.

ssl_certificate_key  /etc/nginx/ssl/<...>-key.pem

ssl_certificate_key 가 가리키는 개인키가 우리 서버에 있다는 뜻이었다.

key.pem 은 존재와 권한만 봤다.

ls -l /etc/nginx/ssl/<...>-key.pem
# -rw------- ... 241

ls -l 로 보니 평문이고 권한은 소유자만으로 걸려 있었다.

cat 은 하지 않았는데 개인키는 값을 보는 순간 화면과 로그와 세션 기록에 남는다.

확인이 목적이면 ls -l 의 출력만으로 충분하고 확인해야 할 것과 열어 보면 안 되는 것을 가르는 것이 이 작업의 조심할 지점이었다.

nginx 설정이 살아 있어도 실제로 그 경로로 오는 것이 있는지는 다른 문제였다.

dig +short <도메인>
# (없음)

dig +short www.<도메인>
# (없음)

dig 에 A 레코드가 안 잡히니 지금 외부 트래픽은 흐르지 않는다.

이것으로 제거해도 되는지의 기준이 정해졌다.

[틀린 기준]  파일이 있나 → 있으니 조심
[맞는 기준]  이름이 해소되나 → 안 되면 제거해도 끊길 서비스가 없다

파일 존재가 아니라 이름이 해소되는지로 판단한다.

dig 에 안 잡히면 아무도 그 주소로 못 오므로 설정을 지워도 끊길 것이 없다. 반대로 conf.d 에서 파일을 지워도 그 이름이 dig 에 남아 있으면 여전히 해소된다.

무엇을 지웠는지가 아니라 밖에서 어떻게 보이는지가 기준이어야 했다.

실제 conf.d 정리는 그 서버를 관리하는 쪽의 소관이라 우리가 손댈 자리가 아니었다.

발견 내용
  설정 파일 위치와 크기
  로드 여부 (확인 방법 포함)
  개인키 존재와 권한 (값은 없음)
  DNS 해소 여부

제거 안전성 판정
  A 레코드 없음 → 제거 가능

남는 것
  제거 실행은 그쪽 소관

nginx -T 결과와 dig 결과와 제거 판정을 같이 넘겼다.

이런 게 있으니 확인해 보라고 하는 것과 이렇고 이래서 제거해도 된다고 하는 것은 받는 쪽의 일이 다르다.

[방치]  "다른 소관"이라며 손도 안 대고 안 알림
[넘김]  실측해서 상태를 확정하고 소관에 전달

앞의 것이 이 건의 시작이었고 문서만 지우고 실물은 다른 소관이라고 하면 그 소관은 그런 것이 있는 줄도 모른다.

넘기려면 무엇을 넘기는지 알려야 하고 그러려면 넘기기 전에 실측이 필요했다.