شكرًا لك - يمكنني تأكيد أن خلاصتي المُصادق عليها يتم إنشاؤها بشكل صحيح من جهتي الآن.
تبدو المشكلة المتبقية في توافق العميل: لا يبدو أن تقويم Google أو Outlook سعيد بالاشتراك مباشرةً في خلاصة ICS مُصادق عليها بهذا الشكل، لذا سأقوم في الوقت الحالي بتجاوز المشكلة عن طريق وضع وكيل عكسي (reverse proxy) من Nginx على مستوى المضيف أمام تثبيت Discourse ذي الحاوية الواحدة وتقديم ملف .ics عادي هناك بدلاً من ذلك.
نظرًا لأنني أستخدم الإعداد القياسي للحاوية الواحدة، أعتقد أن هذا يعني نقل المنافذ 80/443 بعيدًا عن الحاوية، وجعل Discourse يستمع إلى منفذ داخلي عالٍ، ثم جعل وكيل Nginx العكسي (host Nginx proxy) يمرر المنتدى وكذلك يقدم مسار خلاصة التقويم الثابتة.
تقريبًا، الأوامر التي أتوقع استخدامها هي:
# 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. إيقاف حاوية Discourse لتحرير المنافذ 80/443
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 على وكيل Nginx العكسي للمضيف بدلاً من ذلك.
ثم أعد البناء:
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
ثم احصل على شهادة Let’s Encrypt باستخدام Certbot ودعه يقوم بتحديث إعداد 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";
}
}
عند هذه النقطة، يمكنني استخدام برنامج نصي/مؤقت على المضيف لجلب خلاصة ICS المُصادق عليها من Discourse وكتابتها في:
/var/www/private-calendar/ethan.ics
والتي يمكن لتقويم Google / Outlook الاشتراك فيها كرابط URL لخلاصة ICS عامة عادية.
لذا، من وجهة نظري، يبدو جانب Discourse قد تم حله الآن؛ الفجوة المتبقية عمليًا هي أن عملاء التقويم الرئيسيين لا يتعاملون مع خلاصات ICS المُصادق عليها بشكل جيد، ولهذا السبب ألجأ إلى نهج الوكيل العام/الملف الثابت في الوقت الحالي.
أفترض أيضًا أن Certbot هو المسار الأبسط هنا، لأنه يمكنه إدارة إصدار/تجديد Let’s Encrypt مباشرةً مقابل وكيل Nginx للمضيف. يمكنني أيضًا استخدام acme.sh، لكن انطباعي هو أنه سيكون خيارًا يدويًا أكثر منه المسار الأكثر وضوحًا لهذا الإعداد المحدد.
