감사합니다 - 인증된 피드 자체가 제 쪽에서 이제 제대로 생성되고 있음을 확인했습니다.
남은 문제는 클라이언트 호환성으로 보입니다. Google Calendar이나 Outlook 모두 현재 이 형태의 인증된 ICS 피드에 직접 구독하는 것을 지원하지 않는 것 같아, 당분간 단일 컨테이너 Discourse 설치 앞에 호스트 레벨 Nginx 리버스 프록시를 두고, 대신 거기서 일반 .ics 파일을 서빙하는 방식으로 우회할 계획입니다.
표준 단일 컨테이너 구성을 사용하고 있으므로, 이는 컨테이너에서 포트 80/443을 해제하고, Discourse가 내부 고(高) 포트에서 리스닝하도록 한 뒤, 호스트 Nginx가 포럼을 프록시하고 정적 캘린더 피드 경로를 서빙하도록 하는 것을 의미할 것으로 생각합니다.
예상되는 명령어는 대략 다음과 같습니다:
# 1. 호스트 nginx + certbot 설치
sudo apt update
sudo apt install -y nginx snapd
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/bin/certbot
# 2. 포트 80/443을 해제할 수 있도록 Discourse 컨테이너 중지
cd /var/discourse
sudo ./launcher stop app
# 3. 컨테이너 설정을 편집하여 Discourse가 더 이상 80/443에 직접 바인딩하지 않도록 함
sudo nano /var/discourse/containers/app.yml
그런 다음 app.yml에서 expose 섹션을 다음에서:
expose:
- "80:80"
- "443:443"
다음과 같이 변경합니다:
expose:
- "127.0.0.1:8080:80"
그리고, 존재한다면 컨테이너 SSL / Let’s Encrypt 템플릿을 제거하여 TLS가 호스트 리버스 프록시에서 종료되도록 합니다.
그리고 재빌드합니다:
cd /var/discourse
sudo ./launcher rebuild app
그리고 다음과 같은 호스트 레벨 Nginx 사이트를 생성합니다:
sudo nano /etc/nginx/sites-available/discourse
다음과 같은 내용으로:
server {
listen 80;
listen [::]:80;
server_name forum.example.com;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
location /private-calendar/ethan.ics {
alias /var/www/private-calendar/ethan.ics;
default_type text/calendar;
add_header Content-Type "text/calendar; charset=utf-8";
}
}
활성화하고 재로드합니다:
sudo mkdir -p /var/www/private-calendar
sudo mkdir -p /var/www/certbot
sudo ln -s /etc/nginx/sites-available/discourse /etc/nginx/sites-enabled/discourse
sudo nginx -t
sudo systemctl reload nginx
그리고 Certbot으로 Let’s Encrypt 인증서를 발급받고 Nginx 구성이 업데이트되도록 합니다:
sudo certbot --nginx -d forum.example.com
sudo nginx -t
sudo systemctl reload nginx
그 후, Nginx 구성에는 일반적으로 HTTPS 서버 블록도 포함되게 됩니다. 예:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name forum.example.com;
ssl_certificate /etc/letsencrypt/live/forum.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/forum.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
location /private-calendar/ethan.ics {
alias /var/www/private-calendar/ethan.ics;
default_type text/calendar;
add_header Content-Type "text/calendar; charset=utf-8";
}
}
그 시점에 호스트에서 스크립트/타이머를 사용하여 인증된 Discourse ICS를 가져와서 다음을 작성할 수 있습니다:
/var/www/private-calendar/ethan.ics
Google Calendar / Outlook은 이를 일반 공개 ICS URL로 구독할 수 있습니다.
따라서 제 관점에서 Discourse 쪽은 이제 해결된 것으로 보입니다. 실질적으로 남은 간극은 주로 주요 캘린더 클라이언트가 인증된 ICS 피드를 잘 처리하지 못한다는 점이며, 이것이 제가 당분간 공개 프록시/정적 파일 방식으로 전환하는 이유입니다.
또한 Certbot이 여기서 가장 단순한 경로라고 가정합니다. 왜냐하면 호스트 Nginx에 대해 Let’s Encrypt 발급/갱신을 직접 관리할 수 있기 때문입니다. acme.sh를 사용할 수도 있지만, 제 인상으로는 이 특정 설정에 대해 가장 직관적인 경로보다는 수동 선택에 가까울 것 같습니다.
