แก้ไขข้อผิดพลาด "ไม่สามารถเชื่อมต่อกับ Kopano Core" ใน Kopano WebApp

วิธีที่เร็วที่สุดในการแก้ไขข้อผิดพลาด “ไม่สามารถเชื่อมต่อกับ Kopano Core” ใน Kopano WebApp คือการตรวจสอบว่าส่วนใดในสามส่วนนี้มีปัญหา ได้แก่Kopano Core เอง จุดเชื่อมต่อระหว่าง WebApp กับ Coreหรือส่วน PHP-MAPIที่ WebApp ใช้ในการสื่อสารกับ Core การรีสตาร์ททุกอย่างอาจดูเหมือนแก้ไขปัญหาได้ในบางครั้ง แต่จะซ่อนสาเหตุที่แท้จริงและอาจทำให้การวินิจฉัยความล้มเหลวที่เกิดขึ้นซ้ำๆ ทำได้ยากขึ้น

เอกสารอย่างเป็นทางการของ Kopano เกี่ยวกับ WebApp ระบุว่า WebApp ขึ้นอยู่กับphp-mapiและDEFAULT_SERVERการตั้งค่าของมันจะควบคุมว่า WebApp เชื่อมต่อกับ Kopano Core ที่ใด ตัวเลือกที่ระบุไว้ ได้แก่ ซ็อกเก็ต Unix ในเครื่อง, HTTP บนพอร์ต 236 และ HTTPS บนพอร์ต 237 ดูเอกสารการกำหนดค่า Kopano WebAppและคู่มือผู้ดูแลระบบ Kopano Core

หมายเหตุสำคัญเกี่ยวกับเวอร์ชัน:คู่มือผู้ดูแลระบบสาธารณะของ Kopano ที่มีอยู่ ณ เวลาที่เขียนบทความนี้ มีอายุเก่ากว่าระบบปฏิบัติการ Linux รุ่นปัจจุบันหลายรุ่น ดังนั้น ชื่อแพ็กเกจ เวอร์ชัน PHP ตัวห่อบริการ และตำแหน่งจัดเก็บไฟล์บันทึก อาจแตกต่างกันไปในการติดตั้งของคุณ รูปแบบการเชื่อมต่อและตัวเลือกการกำหนดค่าที่อธิบายไว้ด้านล่างนี้ อ้างอิงจากเอกสารที่เผยแพร่โดย Kopano เอง แต่คุณควรตรวจสอบเส้นทางในเครื่องและเวอร์ชันแพ็กเกจก่อนที่จะเปลี่ยนแปลงเซิร์ฟเวอร์ที่ใช้งานจริง

คุณควรลองวิธีแก้ไขใดก่อน?

เริ่มจากอาการที่ตรงกับระบบของคุณมากที่สุดก่อนที่จะทำการเปลี่ยนแปลงทุกอย่างพร้อมกัน

1. Kopano Core กำลังทำงานอยู่จริงหรือไม่?

ตรวจสอบกระบวนการทำงานของเซิร์ฟเวอร์ก่อนแก้ไขการตั้งค่าเว็บแอปพลิเคชัน สำหรับระบบปฏิบัติการที่ใช้ systemd ให้ใช้คำสั่ง:

sudo systemctl status kopano-server

หากอุปกรณ์ทำงานผิดพลาดหรือไม่ทำงาน โปรดตรวจสอบบันทึกการทำงานล่าสุดก่อนที่จะเริ่มการทำงานใหม่:

sudo journalctl -u kopano-server -n 100 --no-pager

ตรวจสอบหาข้อผิดพลาดในการเชื่อมต่อฐานข้อมูล ความล้มเหลวในการวิเคราะห์การกำหนดค่า ปัญหาด้านสิทธิ์ ไฟล์หาย หรือข้อผิดพลาดในการเริ่มต้นระบบ เอกสารหลักของ Kopano ระบุว่าโดยทั่วไปแล้วการเปลี่ยนแปลงการกำหนดค่าจำเป็นต้องรีสตาร์ทส่วนประกอบที่ได้รับผลกระทบ ตัวอย่างเช่น ด้วยคำสั่ง ` kbink start` systemctl restart kopano-<component>นอกจากนี้ยังระบุ/etc/kopano/server.cfgถึงไฟล์การกำหนดค่าปกติสำหรับkopano-server`kbink start` ด้วย ดู ที่หัวข้อ กำหนด ค่าส่วนประกอบ KC

เลือกวิธีนี้เมื่อ:บริการหยุดทำงานอย่างชัดเจน เกิดข้อผิดพลาดหลังจากเริ่มต้น หรือเครื่องมือ Kopano อื่นๆ ก็ไม่สามารถสื่อสารกับ Core ได้ การแก้ไข WebApp ก่อนจะเป็นการแก้ปัญหาที่ปลายเหตุเท่านั้น

ข้อแลกเปลี่ยน:การรีสตาร์ทเป็นการพยายามกู้คืนที่เร็วที่สุด แต่หากกระบวนการล้มเหลวอีกครั้งทันที คุณจำเป็นต้องใช้ข้อมูลจากบันทึกการทำงาน ในระบบที่ใช้งานจริง ควรบันทึกรายละเอียดความล้มเหลวก่อนรีสตาร์ท เพื่อไม่ให้สูญเสียหลักฐานที่ชัดเจนที่สุด

2. เว็บแอปชี้ไปยังเอนด์พอยต์ Kopano Core ที่ถูกต้องหรือไม่?

ใน WebApp การตั้งค่าหลักจะอยู่DEFAULT_SERVERในconfig.phpเอกสารคู่มือ WebApp อย่างเป็นทางการของ Kopano ซึ่งมีตัวอย่างดังต่อไปนี้:

define("DEFAULT_SERVER", "default:");
define("DEFAULT_SERVER", "file:///var/run/kopano/server.sock");
define("DEFAULT_SERVER", "http://localhost:236/kopano");
define("DEFAULT_SERVER", "https://localhost:237/kopano");

โดยค่าเริ่มต้นที่ระบุไว้ในเอกสาร จะเชื่อมต่อกับซ็อกเก็ตภายในเครื่องfile:///var/run/kopano/server.sockซึ่งโดยปกติแล้วจะเป็นตัวเลือกที่ง่ายที่สุดเมื่อ WebApp และ Core ทำงานบนเครื่องเดียวกัน หากทำงานบนเครื่องที่แยกจากกัน ซ็อกเก็ต Unix ภายในเครื่องจะไม่สามารถใช้งานได้ คุณต้องใช้ปลายทาง HTTP หรือ HTTPS ที่สามารถเข้าถึงได้แทน เอกสารเกี่ยวกับการปรับแต่งประสิทธิภาพของ Kopano อธิบายถึงโฮสต์ WebApp ที่เชื่อมต่อกับเซิร์ฟเวอร์ Kopano แยกต่างหากผ่านพอร์ต 236 หรือพอร์ต 237 สำหรับ SSL ดูการปรับแต่งประสิทธิภาพของ Kopano และการกำหนดค่าเซิร์ฟเวอร์แบบแยกส่วน

ซ็อกเก็ต Unix ภายในเครื่อง:โดยทั่วไปแล้วเป็นตัวเลือกที่มีค่าใช้จ่ายน้อยที่สุดบนโฮสต์เดียว และหลีกเลี่ยงการเปิดเผยบริการ TCP เพียงเพื่อการเข้าถึงเว็บแอปพลิเคชันภายในเครื่อง ค่าใช้จ่ายคือซ็อกเก็ตต้องมีอยู่ และกระบวนการของเว็บเซิร์ฟเวอร์ต้องสามารถใช้งานได้

HTTP บนพอร์ต 236:ทดสอบได้ง่ายกว่าบนโฮสต์ต่างๆ และเหมาะสำหรับเครือข่ายภายในที่เชื่อถือได้เมื่อสถาปัตยกรรมความปลอดภัยของคุณอนุญาต ข้อเสียคือข้อมูลจะไม่ถูกเข้ารหัสที่เลเยอร์การขนส่งของ Kopano

HTTPS บนพอร์ต 237:เหมาะสำหรับกรณีที่ต้องการการเข้ารหัสข้อมูลระหว่าง WebApp และ Core การใช้งาน HTTPS จะทำให้ต้องมีการตั้งค่าและตรวจสอบใบรับรอง เอกสารการกำหนดค่าพิเศษของ Kopano แสดงให้เห็นว่า WebApp ใช้ HTTPS DEFAULT_SERVERและในบางกรณีใช้ใบรับรองไคลเอ็นต์ ดูที่การกำหนดค่า Core พิเศษของ Kopano

3. หากคุณใช้ Unix socket ซ็อกเก็ตนั้นมีอยู่จริงหรือไม่ และเว็บเซิร์ฟเวอร์สามารถเข้าถึงได้หรือไม่

สำหรับการใช้งานบนโฮสต์เดียวกัน ให้ตรวจสอบซ็อกเก็ตด้วยตนเอง:

ls -l /var/run/kopano/server.sock
file /var/run/kopano/server.sock
ss -xl | grep kopano

หากไฟล์หายไป อย่าสร้างไฟล์ปกติที่มีชื่อนั้น ซ็อกเก็ตจะถูกสร้างขึ้นโดยเซิร์ฟเวอร์ Kopano ที่กำลังทำงานอยู่ ดังนั้น ซ็อกเก็ตที่หายไปจึงมักชี้ไปที่การเริ่มต้นระบบ Core, เส้นทางซ็อกเก็ตที่เปลี่ยนแปลง หรือการตั้งค่าที่ไม่ตรงกัน

หากซ็อกเก็ตมีอยู่ ให้ตรวจสอบความเป็นเจ้าของและโหมดของซ็อกเก็ตนั้น ผู้ใช้เว็บเซิร์ฟเวอร์ต้องสามารถเข้าถึงซ็อกเก็ตผ่านเส้นทางไดเร็กทอรีได้ ขึ้นอยู่กับการแจกจ่ายระบบปฏิบัติการของคุณ บัญชีเว็บเซิร์ฟเวอร์อาจเป็นwww-data, apache, หรือผู้ใช้เฉพาะบริการอื่น ๆ หลีกเลี่ยงการแก้ไขข้อผิดพลาดด้านสิทธิ์ด้วยโหมดกว้าง ๆ เช่นchmod 777; เพราะจะเพิ่มความเสี่ยงและอาจถูกเขียนทับในครั้งต่อไปที่บริการสร้างซ็อกเก็ตขึ้นใหม่

แนวทางที่ดีกว่าคือการจัดตำแหน่ง WebApp ให้ตรงกับตำแหน่งซ็อกเก็ตที่สร้างโดย Kopano จากนั้นใช้สิทธิ์กลุ่มหรือบริการที่กำหนดไว้ในระบบปฏิบัติการ หากเซิร์ฟเวอร์ของคุณได้รับการปรับแต่งแล้ว ให้เปรียบเทียบการกำหนดค่า Core กับปลายทาง WebApp ก่อนที่จะเปลี่ยนความเป็นเจ้าของ

4. ถ้า Core ทำงานได้ปกติ แต่ WebApp ยังคงแจ้งว่าไม่สามารถเชื่อมต่อได้ จะทำอย่างไร?

ตรวจสอบ PHP-MAPI ต่อไป Kopano ระบุไว้อย่างชัดเจนว่า WebApp ขึ้นอยู่กับ PHP-MAPI php-mapiการตรวจสอบการกำหนดค่า WebApp ยังสามารถทดสอบความพร้อมใช้งานของ PHP และ PHP-MAPI ได้อีกด้วย ดูเอกสารประกอบ WebApp Config.php

การตรวจสอบ CLI อย่างรวดเร็วมีดังนี้:

php -m | grep -i mapi

อย่างไรก็ตาม การทดสอบนี้มีข้อจำกัดที่สำคัญอย่างหนึ่งคือ อินเทอร์เฟซบรรทัดคำสั่งของ PHP อาจไม่ได้ใช้การกำหนดค่าเดียวกันกับ Apache PHP, PHP-FPM หรือการผสานรวมเว็บเซิร์ฟเวอร์อื่นๆ ผลลัพธ์ CLI ที่เป็นบวกพิสูจน์ได้เพียงว่าสภาพแวดล้อม CLI มองเห็นโมดูลนั้นแล้ว

การตรวจสอบติดตามผลที่เป็นประโยชน์ ได้แก่:

php --ini
php -i | grep -i mapi

จากนั้นเปรียบเทียบกับค่าการตั้งค่า PHP ที่ใช้โดยเว็บเซิร์ฟเวอร์หรือพูล FPM ของคุณ หากแพ็กเกจหายไปหรือเวอร์ชันไม่เข้ากัน ให้ติดตั้ง ชุดแพ็กเกจ Kopano Core/PHP-MAPI ที่ตรงกันจากที่เก็บแพ็กเกจที่เหมาะสมกับระบบปฏิบัติการและรุ่น Kopano ของคุณ อย่าผสม PHP-MAPI เวอร์ชันที่ไม่เกี่ยวข้องกันเพียงเพื่อให้ส่วนขยายปรากฏในไฟล์php -m.

เลือกเส้นทางนี้เมื่อ: kopano-serverการเชื่อมต่อมีสุขภาพดี ปลายทางถูกต้องและสามารถเข้าถึงได้ แต่เว็บแอปพลิเคชันล้มเหลวระหว่างการตรวจสอบการเชื่อมต่อหรือการกำหนดค่าฝั่ง PHP

ข้อควรพิจารณา:การติดตั้งใหม่หรืออัปเกรดแพ็กเกจอาจเป็นวิธีแก้ไขที่ถูกต้องเมื่อไฟล์ไบนารีไม่ตรงกัน แต่จะเปลี่ยนแปลงระบบมากกว่าการแก้ไขเพียงจุดเดียว ตรวจสอบเวอร์ชันของแพ็กเกจก่อนและวางแผนการอัปเกรดในระบบการผลิตให้เหมาะสม

คุณควรจะรีสตาร์ท Apache, PHP-FPM หรือ Kopano Server หรือไม่?

รีสตาร์ทส่วนประกอบที่มีการเปลี่ยนแปลงการตั้งค่าหรือโมดูลจริง

• หากคุณทำการเปลี่ยนแปลง ใดๆ /etc/kopano/server.cfgโปรดรีสตาร์ทkopano-serverเครื่อง
• หากคุณติดตั้งหรือเปิดใช้งานส่วนขยาย PHP โปรดรีสตาร์ทเลเยอร์การให้บริการ PHP ที่ WebApp ใช้ เช่น Apache หรือบริการ PHP-FPM ที่เกี่ยวข้อง
• หากคุณแก้ไขเฉพาะไฟล์การกำหนดค่า PHP ของ WebApp เท่านั้น โดยปกติแล้วไม่จำเป็นต้องรีสตาร์ท Kopano Core ทั้งหมด เว้นแต่ว่าปลายทางของ Core เองก็มีการเปลี่ยนแปลงด้วย

คำสั่งเว็บเซอร์วิสที่ใช้จะแตกต่างกันไปตามการแจกจ่ายและแพ็กเกจ PHP ตัวอย่างเช่น อาจเป็นsystemctl restart apache2, systemctl restart httpd, หรือหน่วย PHP-FPM ที่มีเวอร์ชันต่างๆ ควรใช้ชื่อเซอร์วิสที่มีอยู่บนโฮสต์ของคุณแทนที่จะคัดลอกคำสั่งโดยไม่ดูข้อมูลให้ชัดเจน

แล้วเซิร์ฟเวอร์ Core และไฟร์วอลล์ระยะไกลล่ะ?

หาก WebApp และ Kopano Core แยกจากกัน ให้ตรวจสอบการกำหนดเส้นทางและตัวรับฟังที่กำหนดค่าไว้ก่อน ก่อนที่จะโทษ WebApp เอกสารของ Kopano อธิบายว่าการเข้าถึง HTTP อยู่บนพอร์ต 236 และการเข้าถึง SSL อยู่บนพอร์ต 237 ดังนั้น การติดตั้งใช้งานระยะไกลจึงเพิ่มโหมดความล้มเหลวหลายอย่างที่การติดตั้งใช้งาน Unix-socket ในเครื่องไม่มี ได้แก่ กฎไฟร์วอลล์ การผูกตัวรับฟัง DNS ใบรับรอง TLS พร็อกซีแบบย้อนกลับ และนโยบายเครือข่ายระดับกลาง

สำหรับเอนด์พอยต์ HTTP คุณสามารถตรวจสอบได้อย่างน้อยที่สุดว่าสามารถเข้าถึงตัวรับฟัง TCP จากโฮสต์ของเว็บแอปพลิเคชันได้หรือไม่:

nc -vz core.example.net 236

สำหรับ HTTPS ให้ตรวจสอบเอนด์พอยต์ TLS แยกต่างหากด้วยเครื่องมือที่เหมาะสมกับนโยบายใบรับรองของคุณ การเชื่อมต่อ TCP ที่สำเร็จไม่ได้หมายความว่าการตรวจสอบสิทธิ์ WebApp หรือการดำเนินการ MAPI จะสำเร็จเสมอไป แต่การเชื่อมต่อที่ล้มเหลวจะพิสูจน์ได้ว่า PHP-MAPI ไม่สามารถเข้าถึงบริการที่กำหนดค่าไว้ผ่านที่อยู่และพอร์ตนั้นได้

หากคุณใช้รีเวิร์สพร็อกซี โปรดจำไว้ว่าเอกสารของ Kopano กำหนดให้เส้นทางพร็อกซีและการแมปแบ็กเอนด์ต้องสอดคล้องกับ URL ที่เว็บแอปพลิเคชันใช้ คู่มือ Core อย่างเป็นทางการยังระบุถึงข้อควรพิจารณาเกี่ยวกับ HTTP/1.1 สำหรับการใช้พร็อกซีกับทราฟฟิกของ Kopano ด้วย ดูที่การกำหนดค่าส่วนประกอบ Kopano Core

ลำดับการวินิจฉัยที่ใช้งานได้จริงซึ่งช่วยลดการเปลี่ยนแปลงที่ไม่จำเป็นให้น้อยที่สุด

1. ตรวจสอบkopano-serverสถานะหากล้มเหลว ให้แก้ไขส่วนหลักก่อน
2. อ่านบันทึก Core logsต้องแก้ไขปัญหาฐานข้อมูลหรือการตั้งค่าก่อนที่ WebApp จะสามารถเชื่อมต่อได้
3. ตรวจสอบDEFAULT_SERVERยืนยันว่าตรงกับซ็อกเก็ตภายในเครื่องหรือปลายทาง HTTP/HTTPS ระยะไกลที่ถูกต้อง
4. ทดสอบซ็อกเก็ตหรือตัวรับฟังเครือข่ายจริงเพื่อแยกความล้มเหลวในการรับส่งข้อมูลออกจากปัญหาของ PHP
5. ตรวจสอบ PHP-MAPI ในสภาพแวดล้อมการทำงานของเว็บอย่าพึ่งพาเฉพาะสภาพแวดล้อม PHP แบบ CLI เพียงอย่างเดียว
6. รีสตาร์ทเฉพาะบริการที่ได้รับผลกระทบ จากนั้นทดสอบ WebApp อีกครั้ง และตรวจสอบบันทึกหากข้อผิดพลาดยังคงอยู่

ลำดับขั้นตอนนี้ปลอดภัยกว่าการเริ่มต้นด้วยการติดตั้งแพ็กเกจใหม่ เนื่องจากเป็นการรักษาหลักฐานและทำให้การทดสอบแต่ละครั้งมีความหมาย นอกจากนี้ยังช่วยหลีกเลี่ยงข้อผิดพลาดในทางตรงกันข้าม นั่นคือการรีสตาร์ท WebApp หรือ Apache ซ้ำๆ เมื่อ Kopano Core เองไม่สามารถเริ่มต้นได้

เมื่อใดที่การเปลี่ยนค่า DEFAULT_SERVER ไม่ใช่วิธีแก้ปัญหาที่ถูกต้อง?

อย่าเปลี่ยนค่าDEFAULT_SERVERเพียงเพราะหน้าล็อกอินแสดงข้อผิดพลาดในการเชื่อมต่อ หากค่าปัจจุบันชี้ไปยังอินสแตนซ์ Core ที่ต้องการอย่างถูกต้อง การเปลี่ยนค่าอาจซ่อนปัญหาที่แท้จริงหรือส่งผู้ใช้ไปยังแบ็กเอนด์ที่ไม่ถูกต้อง

ตัวอย่างเช่น การแทนที่default:ด้วยhttp://localhost:236/kopanoไม่ใช่การอัปเกรดโดยเนื้อแท้ มันเปลี่ยนการขนส่งจากซ็อกเก็ตเริ่มต้นในเครื่องที่ระบุไว้เป็น TCP ซึ่งอาจมีประโยชน์สำหรับการดีบักหรือสำหรับโทโพโลยีที่ต้องการ TCP แต่ก็เปลี่ยนความปลอดภัยและพื้นผิวการทำงานด้วย สำหรับการตั้งค่าบนโฮสต์เดียวกัน การแก้ไขซ็อกเก็ตที่หายไปหรือไม่สามารถเข้าถึงได้มักจะสะอาดกว่าการเปิดตัวรับฟังอีกตัวหนึ่ง

ถ้าปัญหายังคงเกิดขึ้น คุณควรทำอย่างไร?

ในขั้นตอนนี้ ให้รวบรวมหลักฐานจากทั้งสองฝ่าย:

• ค่า ที่แท้จริงDEFAULT_SERVERโดยลบข้อมูลประจำตัวหรือข้อมูลลับออกไปแล้ว
• systemctl status kopano-serverและรายการบันทึกประจำวันของเซิร์ฟเวอร์ Kopano ล่าสุด;
• ข้อมูลการเป็นเจ้าของซ็อกเก็ตหรือข้อมูลผู้ฟังระยะไกล;
• เวอร์ชัน PHP และส่วนขยาย MAPI ที่โหลดในรันไทม์การให้บริการเว็บ
• บันทึกข้อผิดพลาดของ WebApp/PHP เกี่ยวกับความพยายามในการเข้าสู่ระบบที่ไม่สำเร็จ

เอกสารประกอบการใช้งาน WebApp ของ Kopano ระบุว่า การบันทึกข้อผิดพลาด PHP เปิดใช้งานผ่านการตั้งค่า PHP config.phpและเตือนไม่ให้แสดงข้อผิดพลาดโดยตรง เนื่องจากอาจทำให้การตอบสนอง JSON เสียหายได้ ดังนั้น บันทึกฝั่งเซิร์ฟเวอร์จึงเป็นแหล่งข้อมูลการวินิจฉัยที่ดีกว่า โปรดดูการตั้งค่าการบันทึก WebApp อย่างเป็นทางการก่อนที่จะเพิ่มระดับความละเอียดในการแสดงผล

เมื่อคุณระบุได้แล้วว่าความล้มเหลวเกิดจากการเริ่มต้นระบบ Core, การขนส่ง, สิทธิ์การเข้าถึง, PHP-MAPI หรือเครือข่ายระยะไกล ให้ใช้วิธีแก้ไขที่เล็กที่สุดที่จัดการกับเลเยอร์นั้น วิธีนี้จะน่าเชื่อถือกว่าการมองว่า "ไม่สามารถเชื่อมต่อกับ Kopano Core" เป็นข้อผิดพลาดเดียวที่มีวิธีแก้ไขแบบเดียวครอบคลุมทุกอย่าง