Let's Encrypt SSL 인증서가 연속 두 번째로 자동으로 갱신되지 않음

지원
1

안녕하세요, 여러분. 트러블슈팅에 도움이 필요합니다. 두 번째로 연속해서 Let’s Encrypt SSL 인증서가 자동으로 갱신되지 않았습니다. 이곳의 관련 스레드를 읽으면서, 이전 인증서를 삭제하고 앱을 다시 구축하여 인증서를 갱신하는 방법을 알아냈습니다. 이렇게 하면 다음에는 자동으로 갱신될 것이라고 생각했습니다. 하지만 그렇지 않았습니다.

인증서를 갱신하려고 시도하는 cron 작업이 어디에서 실행되고 있다는 증거를 찾을 수 없습니다. Docker 컨테이너 내부가 아닌 호스트 머신의 여러 위치를 확인해야 한다고 추정합니다. 제 추측이 맞나요? crontab -l은 "no crontab for root"라고 표시되고, /etc/cron*에서도 아무것도 찾을 수 없습니다.

그 결과, 제 서버가 (1) 인증서 갱신을 시도하지 않고 있는지, 아니면 (2) 시도하고 있지만 실패하고 있는지를 확신할 수 없습니다. 이 문제를 트러블슈팅하는 과정을 안내해 주실 분이 있을까요?

불행히도 인증서를 새로 프로비저닝하기 위해 shared/standalone/{letsencrypt,ssl}을 삭제했기 때문에, 과거 로그를 살펴볼 수 있는 상태가 아닙니다. 시스템이 인증서 갱신을 시도할 때 로그를 확인할 수 있도록 cron 작업이 설치되어 있는지 최소한 어떻게 확인할 수 있을까요?

감사합니다.

2

이것이 마지막으로 이런 일이 발생한 것 같습니다. 12월에 수정이 적용되었어요:

3

정말 감사합니다. 하지만 저는 예정된 갱신이 실제로 이루어질지 확인하기 위해 설정을 직접 살펴보고 싶습니다. 해당 설정을 어떻게 확인하는지 모르기 때문에, 지금 도움을 요청하는 것입니다.

아마도 크론 작업(cron job)이 하나 있어야 할 것 같은데, 어디에 있나요? 제 서버 목록에서는 보이지 않습니다. 이것이 정말 크론 작업이 아니라 Rails의 예약 작업(scheduled task)일까요?

호스트 시스템의 /var/discourse/shared/standalone/letsencrypt/acme.sh.log 파일에서 Discourse가 제 SSL 인증서를 확인했고, 응답이 "아직 유효합니다(It’s still valid)"라고 표시되어 있었습니다. 따라서 Discourse가 제때 인증서를 갱신하려고 시도할 것이라는 증거라고 생각합니다.

이제 그 “크론” 작업이 어떻게 구성되었는지 알고 싶습니다. 이것이 정말 Linux 레벨의 cron 작업인지, 아니면 whenever 같은 도구를 사용한 Rails의 반복 예약 작업일 뿐인지요. 소스 코드를 살펴보지 않고도 이 부분을 검토하고 확인할 수 있을까요? Rails 콘솔이나 2026년 현재 그 대안이 되는 도구를 통해 이것을 찾을 수 있을까요? (오래 전부터 Rails로 개발을 하지 않았습니다.)

감사합니다.

4

아, 그리고 이 결함의 원인이 결국 문서화되지 않고, 명확하지 않으며, 명백하게 의도되지 않은 마법 같은 단축키였다는 것을 마침내 깨달았습니다. “/로 시작하면 반드시 정규식이어야 한다.” 아직 전체 맥락을 완전히 이해하지는 못했지만, 그렇게 보입니다.

이것이 바로 덕 타이핑(Duck Typing) 문화의 모습입니다: 놀라운 유연성과 함께, 문서로 남기지 않으면 클라이언트가 놀라는 위험이 따릅니다. :wink:

Pups::ReplaceCommand를 강화하여 to가 정규식처럼 보이는지 더 신중하게 확인하는 것이 현명해 보입니다. 아니면 대체 텍스트로 취급하는 대신 무언가를 eval()하도록 가정하는 그 동작을 수정하는 것이겠죠.

이건 아무도 시간과 에너지가 없어 하지 않는 잡무(청소 작업)에 해당한다고 추정합니다. ReplaceCommand가 어떻게 동작해야 하는지 도움이 되는 예시를 알려주신다면, 저도 시간과 에너지를 조금 기부할 수 있을 것 같습니다.

적어도 무슨 일이 일어나고 있는지 더 잘 알게 되었지만, 그 지식은 이 문장을 다 쓰기 전에 이미 퇴색하기 시작했습니다. :person_shrugging: