แก้ปัญหา

แต่ละหัวข้อขึ้นต้นด้วยข้อความที่คุณเห็นบนจอตรงตามตัวอักษร คุณจึงค้นหาข้อความนั้นในหน้านี้ได้ ข้อความของตัวติดตั้งและสคริปต์ deploy เองมีอยู่ในตารางบนหน้าติดตั้งบน VPSด้วย

ในการติดตั้งแบบ managed คำสั่งนี้แสดง log ของแอป หลายหัวข้อด้านล่างใช้คำสั่งนี้

sudo docker compose -p tomecms -f /opt/tome-cms/compose.managed.yaml \
  --env-file /etc/tome-cms/tome-cms.env \
  --env-file /var/lib/tome-cms/updater/image.env logs --tail 100 app

การติดตั้ง

TOME_CMS_PUBLIC_URL is not set. หรือ S3_ENDPOINT is not set.

ตัวติดตั้งอ่านที่อยู่ทั้งสองจาก shell ที่ใช้รัน และ shell นี้ไม่มีค่าเหล่านั้น SSH session ใหม่ หรือ sudo -i จะเริ่มโดยไม่มีค่าที่คุณ export ไว้ก่อนหน้า ให้ export อีกครั้งใน shell เดียวกัน ตามขั้นที่ 2 ของหน้าติดตั้งบน VPS แล้วจึงรันตัวติดตั้ง

TOME_CMS_PUBLIC_URL requires HTTPS without credentials; configure TLS separately.

ที่อยู่นั้นไม่ใช่ที่อยู่ https:// หรือมีชื่อผู้ใช้หรือรหัสผ่านอยู่ข้างใน ให้ใช้ที่อยู่ https:// ธรรมดาที่ DNS ชี้มาที่เซิร์ฟเวอร์ ตัวติดตั้งของ 1.0.0 แสดงข้อความนี้ด้วยเมื่อไม่ได้กำหนดที่อยู่เลย เวอร์ชันหลังจากนั้นจะบอกตรง ๆ ว่ายังไม่ได้กำหนด

Port 4321 is unavailable. (หรือ 5432, 9000)

มีโปรแกรมบนเซิร์ฟเวอร์ใช้พอร์ตนั้นอยู่แล้ว ส่วนใหญ่เป็นการติดตั้ง TomeCMS ครั้งก่อน เช่น รุ่น 0.x คำสั่งนี้บอกว่าเป็นโปรแกรมไหน

ss -tlnp | grep -E ':(4321|9000|5432) '

การติดตั้งแบบ managed ต้องใช้เซิร์ฟเวอร์ใหม่ ให้ติดตั้งบนเครื่องใหม่ หรือลบการติดตั้งเดิมออกก่อน ถ้าแน่ใจว่าไม่ต้องใช้แล้วและมีชุดสำรองของมันไว้

Checkout must match the exact stable release tag.

โฟลเดอร์ที่คุณรันตัวติดตั้งไม่ใช่โค้ดที่ clone มาจาก tag ของ release แบบไม่มีอะไรถูกแก้ เช่น clone มาจาก main ซึ่งเดินหน้าไปแล้ว ตรวจได้ด้วย git describe --tags --exact-match ในโฟลเดอร์นั้น ผลที่ได้ควรเป็นเวอร์ชันที่คุณส่งให้ --version เช่น v1.0.2 ถ้าไม่ใช่ ให้ clone tag ใหม่อีกครั้งตามหน้าเตรียมเซิร์ฟเวอร์ใหม่

ติดตั้ง 1.0.0 แล้วหยุดหลังจากดึง image

ตัวติดตั้งของ 1.0.0 ติดตั้งจนจบไม่ได้บนเซิร์ฟเวอร์ไหนเลย เพราะการตรวจ migration ใน image ล้มเหลว ตัวติดตั้งลบสิ่งที่สร้างไว้ก่อนหยุด จึงไม่ต้องเก็บกวาดอะไร ให้ติดตั้ง 1.0.1 ขึ้นไปแทน

การอัปเดต

การอัปเดตหยุดที่ “เตรียมเข้าสู่โหมดปิดปรับปรุง” และเว็บตอบ 502

บนเซิร์ฟเวอร์ที่ติดตั้งด้วย 1.0.1 หรือ 1.0.2 แอปไม่สนใจสัญญาณให้หยุด ตัวอัปเดตรอ 30 วินาทีแล้วยอมแพ้ และการย้อนกลับก็ล้มเหลวด้วย แอปจึงหยุดค้างอยู่ และเมนู “ระบบ” เริ่มอัปเดตครั้งใหม่ไม่ได้ ตรวจบนเซิร์ฟเวอร์ได้ด้วยคำสั่งนี้

sudo curl --unix-socket /run/tome-cms/updater.sock http://localhost/v1/status

ถ้าได้ "phase":"failed_manual_recovery" พร้อม "backupCreatedAt":null แปลว่าการอัปเดตหยุดก่อนสำรองข้อมูล ฐานข้อมูลและเวอร์ชันที่รันอยู่ยังเหมือนเดิม จากนั้นให้ทำดังนี้

1. รันแอปภายใต้ init แล้วเปิดแอปอีกครั้งด้วยเวอร์ชันที่ใช้อยู่เดิม

   grep -q '^    init: true' /opt/tome-cms/compose.managed.yaml || sed -i '/^  app:$/a\    init: true' /opt/tome-cms/compose.managed.yaml
   cd /opt/tome-cms && docker compose -p tomecms -f compose.managed.yaml \
     --env-file /etc/tome-cms/tome-cms.env \
     --env-file /var/lib/tome-cms/updater/image.env up -d --wait --no-deps --pull never app

2. แยกเก็บการอัปเดตที่ล้มเหลวไว้ โดยรันจากโค้ดที่ checkout ไว้ที่ 1.0.3 ขึ้นไป

   cd /opt/tome-cms-src
   git fetch --depth 1 origin tag v1.0.3
   git checkout --detach v1.0.3
   npm ci
   sudo npm run updater:clear-failed

   คำสั่งนี้เก็บบันทึกของการอัปเดตไว้เป็น job.json.cleared-<id> แล้วรีสตาร์ตตัวอัปเดต

3. อัปเดตอีกครั้งจากเมนู “ระบบ”

This update made a backup before it failed, so it may have changed the database. Follow the recovery steps instead.

npm run updater:clear-failed แยกเก็บเฉพาะการอัปเดตที่หยุดก่อนสำรองข้อมูล การอัปเดตครั้งนี้ไปไกลกว่านั้น และอาจรัน migration ไปแล้ว ให้ทำตามหัวข้อกู้คืนการติดตั้งแบบ managedแทน

ยืนยันด้วย passkey ไม่สำเร็จ อาจถูกยกเลิกไป ลองอีกครั้ง ตอนติดตั้งอัปเดต

ข้อความนี้ขึ้นในหน้า “ระบบ” หลังกดยืนยันการอัปเดต ทั้งที่ passkey ใช้ได้ ออกจากระบบแล้วเข้าใหม่ก็ผ่าน และบรรทัด “สถานะเวอร์ชัน” ก็เปลี่ยนเป็นสีแดงว่า “ตรวจสอบไม่ได้” ทั้งที่ตรวจได้แล้ว

เกิดใน 1.1.0 และก่อนหน้า กับเว็บที่เปิดปลั๊กอิน Cloudflare Turnstile ไว้ การขอ passkey ซ้ำผ่านการตรวจก่อนเข้าสู่ระบบชุดเดียวกับตอนเข้าสู่ระบบ ซึ่งมีแต่หน้าเข้าสู่ระบบที่ผ่านได้ เซิร์ฟเวอร์จึงปฏิเสธ ปุ่ม “ยืนยันตัวตนแล้วสร้างรหัสชุดใหม่” ใต้ “รหัสกู้คืน” ในหน้า “ความปลอดภัย” ก็ชนกำแพงเดียวกัน และขึ้นว่า ไม่ผ่านการตรวจสอบก่อนเข้าสู่ระบบ ไม่มีอะไรถูกเปลี่ยน ตั้งแต่ 1.1.1 จะตรวจเฉพาะตอนที่ยังไม่มี session เจ้าของเว็บที่เข้าสู่ระบบอยู่แล้วจึงไม่ถูกถาม

เวอร์ชันที่กำลังรันเป็นฝ่ายขอ passkey การอัปเดตที่เริ่มจาก 1.1.0 หรือก่อนหน้าจึงยังต้องทำตามนี้

1. เปิด “ปลั๊กอิน” ใต้ “หน้าตาเว็บไซต์” ในกลุ่ม “การตั้งค่า” แล้วปิด “Cloudflare Turnstile” key ทั้งสองยังเก็บอยู่
2. ติดตั้งอัปเดตจากหน้า “ระบบ” ตามหน้าการอัปเดต
3. เปิด “Cloudflare Turnstile” กลับคืน

การเชื่อมต่อเซิร์ฟเวอร์

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

SSH จำ key ของแต่ละเซิร์ฟเวอร์ไว้ และเซิร์ฟเวอร์ที่สร้างใหม่จาก image ใหม่จะได้ key ใหม่ ถ้าคุณสร้างเซิร์ฟเวอร์ใหม่เอง ให้ลบ key เดิมบนคอมพิวเตอร์ของคุณ แล้วเชื่อมต่ออีกครั้งและรับ key ใหม่

ssh-keygen -R your-server-address

ถ้าคุณไม่ได้สร้างเซิร์ฟเวอร์ใหม่ ให้หยุดก่อน และหาให้ได้ว่าทำไม key เปลี่ยน แล้วจึงเชื่อมต่อ

ตัวแอป

/health/ready แสดง "storage":"unavailable"

แอปเข้าถึง bucket ของมีเดียผ่าน S3_ENDPOINT ซึ่งคือ origin ของมีเดีย และ origin นั้นไม่ตอบ ตรวจว่าชื่อโฮสต์ของมีเดียชี้มาที่เซิร์ฟเวอร์ ตามที่หน้าชี้ DNS มาที่เซิร์ฟเวอร์อธิบายไว้ และ Caddy ทำงานอยู่ ด้วย systemctl status caddy

Storage verification is temporarily unavailable. Try finalizing again.

ข้อความนี้ขึ้นตอนอัปโหลดไฟล์ในหน้าแอดมิน หลังจากเบราว์เซอร์อัปโหลดไฟล์แล้ว เซิร์ฟเวอร์จะตรวจไฟล์นั้นใน bucket และครั้งนี้ bucket ไม่ตอบการตรวจนั้น

ใน 1.0.1 และก่อนหน้า เรื่องนี้เกิดกับทุกการอัปโหลด เพราะ SeaweedFS ปฏิเสธการตรวจครั้งแรกที่มาทันทีหลังอัปโหลด และเซิร์ฟเวอร์ยอมแพ้ทันที 1.0.2 จะรอจนผ่านไปได้ ให้อัปเดตจากเมนู “ระบบ” ในหน้าแอดมิน ตามที่หน้าการอัปเดตอธิบายไว้ แล้วอัปโหลดไฟล์อีกครั้ง

ถ้ายังเกิดใน 1.0.2 ขึ้นไป ให้ดู /health/ready ก่อน ตามหัวข้อด้านบน จากนั้นอ่าน log ของแอปด้วยคำสั่งที่ต้นหน้านี้ บรรทัดที่ขึ้นต้นด้วย Upload verification failed: หรือ Image verification failed: จะบอกข้อผิดพลาดของ storage และสถานะของมัน เช่น Unknown 403

พยายามเข้าสู่ระบบบ่อยเกินไป รอสักครู่แล้วลองอีกครั้ง ทั้งที่ลองครั้งเดียว

นี่คือขีดจำกัดการเข้าสู่ระบบ 10 ครั้งใน 15 นาที ใน 1.1.1 และก่อนหน้า แอปนับทุกครั้งที่พยายามเป็นของ reverse proxy ที่อยู่หน้าแอป ไม่ใช่ของคนที่ทำ จึงมีตัวนับเดียวสำหรับทุกคน คำขอที่ล้มเหลวสิบครั้งจากที่ไหนก็ได้ รวมถึงบอต ก็กันเจ้าของเว็บออกจากระบบได้นานถึงสิบห้านาที passkey และบัญชีของคุณไม่เป็นอะไร รอให้ครบเวลา ตั้งแต่ 1.1.2 ผู้เข้าชมแต่ละคนมีตัวนับของตัวเอง ตราบใดที่ proxy ตั้ง X-Forwarded-For ตามที่หน้าตั้ง reverse proxyบอกไว้ ขีดจำกัดของการกู้คืน การติดตั้งและการอัปเดตนับแบบเดียวกัน

The request could not be completed. ตอนลบไฟล์ ลบโลโก้ หรือสร้างรหัสกู้คืนชุดใหม่

ใน 1.0.3 และก่อนหน้า คำขอสามอย่างนี้ส่งออกไปโดยไม่ระบุ content type และ Astro ปฏิเสธคำขอแบบนั้นเมื่อเว็บอยู่หลัง HTTPS proxy ซึ่งการติดตั้งแบบ managed ทุกเครื่องเป็นแบบนั้น ไม่มีอะไรถูกเปลี่ยน ไฟล์ โลโก้ และรหัสชุดเดิมยังอยู่ครบ อัปเดตเป็น 1.0.4 ขึ้นไปจากเมนู “ระบบ” ตามหน้าการอัปเดต แล้วลองอีกครั้ง