หากเว็บคอนโซล Cockpit ไม่สามารถเชื่อมต่อกับโฮสต์ SUSE Linux Enterprise Server (SLES) ได้ ให้ลองทำตามขั้นตอนต่อไปนี้ก่อนhttps://SERVER_IP:9090จากนั้นตรวจสอบว่าcockpit.socketเซิร์ฟเวอร์กำลังทำงานอยู่และไฟร์วอลล์อนุญาตให้ใช้บริการ Cockpit ในโซนที่ใช้โดยอินเทอร์เฟซเครือข่ายของเซิร์ฟเวอร์หรือไม่ ในการติดตั้งแบบมาตรฐาน การตรวจสอบเหล่านี้จะช่วยแก้ไขสาเหตุที่พบบ่อยที่สุด ได้แก่ URL หรือพอร์ตที่ไม่ถูกต้อง ซ็อกเก็ตไม่ทำงาน แพ็กเกจ Cockpit หายไป หรือการเชื่อมต่อขาเข้าถูกบล็อก
คู่มือนี้ใช้ได้กับระบบ SLES ที่ใช้ systemd และมี Cockpit ให้ใช้งานจากที่เก็บผลิตภัณฑ์ที่กำหนดค่าไว้ คู่มือ Cockpit สำหรับ SLES 16 ฉบับปัจจุบันของ SUSE ได้บันทึกคำสั่งการติดตั้งและการเปิดใช้งานซ็อกเก็ตไว้ด้านล่าง ความพร้อมใช้งานและชื่อของแพ็กเกจอาจแตกต่างกันไปตาม Service Pack โมดูล และสิทธิ์การสนับสนุนของ SLES ดังนั้นบนโฮสต์ SLES 15 รุ่นเก่า โปรดตรวจสอบให้แน่ใจว่า Cockpit มีให้ใช้งานในที่เก็บของ SUSE ที่เปิดใช้งานอยู่ก่อนที่จะถือว่าข้อผิดพลาดในการติดตั้งเป็นความผิดพลาดของบริการ
เริ่มจากอาการก่อน
ใช้ข้อผิดพลาดในเบราว์เซอร์เพื่อจำกัดสาเหตุ การหมดเวลาหรือ "ไม่สามารถเข้าถึงเว็บไซต์ได้" มักบ่งชี้ถึงปัญหาเกี่ยวกับการกำหนดเส้นทาง กฎไฟร์วอลล์ หรือตัวรับฟังที่ไม่ทำงาน การเชื่อมต่อที่ถูกปฏิเสธมักหมายความว่าไม่มีอะไรยอมรับการเชื่อมต่อบนที่อยู่และพอร์ตที่เลือก หน้าเข้าสู่ระบบ Cockpit หมายความว่าสามารถเข้าถึงบริการเว็บได้ ข้อผิดพลาดในการตรวจสอบสิทธิ์ในภายหลังเป็นปัญหาบัญชีหรือนโยบายอื่น คำเตือนเกี่ยวกับใบรับรองหมายความว่าการเจรจา HTTPS ไปถึงเซิร์ฟเวอร์แล้ว แต่เบราว์เซอร์ไม่เชื่อถือใบรับรองหรือชื่อของใบรับรองนั้น
ตัวอย่างเช่น สมมติว่าผู้ดูแลระบบไม่สามารถเปิดเซิร์ฟเวอร์ที่มีที่อยู่เป็น192.0.2.25. ทดสอบhttps://192.0.2.25:9090จากเครื่องที่ควรได้รับอนุญาตให้จัดการเซิร์ฟเวอร์นั้นได้ โดยปกติ Cockpit จะใช้ HTTPS บนพอร์ต 9090 การพิมพ์เฉพาะที่อยู่ IP อาจเปิดบริการอื่น และการใช้http://อาจนำไปสู่การเปลี่ยนเส้นทางหรือคำเตือนในเบราว์เซอร์แทนที่จะเป็นหน้าจอเข้าสู่ระบบที่คาดหวัง
1. ตรวจสอบ URL และการเข้าถึง
ตรวจสอบที่อยู่ปัจจุบันของเซิร์ฟเวอร์จากคอนโซล SLES หรือรายการอุปกรณ์ที่เชื่อถือได้ และระบุพอร์ตอย่างชัดเจน:
https://192.0.2.25:9090
จากฝั่งไคลเอ็นต์ ทดสอบว่าสามารถเข้าถึงพอร์ต TCP 9090 ได้หรือไม่ บนเวิร์กสเตชันสำหรับผู้ดูแลระบบ Linux ที่ติดตั้ง netcat ไว้ ให้รันคำสั่งต่อไปนี้:
nc -vz 192.0.2.25 9090
การเชื่อมต่อ TCP ที่สำเร็จพิสูจน์ได้เพียงว่าสามารถเข้าถึงพอร์ตได้เท่านั้น ไม่ได้พิสูจน์ว่าการเข้าสู่ระบบจะใช้งานได้ หากเกิดการหมดเวลา (timeout) ให้ตรวจสอบโซนไฟร์วอลล์ที่ใช้งานอยู่ของเซิร์ฟเวอร์ ไฟร์วอลล์เครือข่ายต้นทาง การกำหนดเส้นทาง และการเข้าถึง VPN หากเกิดการปฏิเสธ (refuse) ให้ตรวจสอบตัวรับฟัง (listener) บนโฮสต์ SLES หากไม่สามารถใช้ netcat ได้ ให้ทดสอบจากเบราว์เซอร์หรือใช้เครื่องมือเชื่อมต่อ TCP ที่ได้รับการอนุมัติอื่นๆ แทนการติดตั้งยูทิลิตี้ที่ไม่ได้รับการอนุมัติบนโฮสต์ที่ใช้งานจริง
2. ตรวจสอบว่าติดตั้ง Cockpit แล้วและเสียบปลั๊กใช้งานได้
เชื่อมต่อผ่าน SSH หรือคอนโซลภายในเครื่อง และตรวจสอบซ็อกเก็ต โดยปกติ Cockpit จะใช้การเปิดใช้งานซ็อกเก็ตด้วย systemd: systemd จะรอรับการเชื่อมต่อขาเข้าในนามของ Cockpit และเริ่มต้นเว็บเซอร์วิสเมื่อมีการร้องขอ ด้วยเหตุนี้ หน่วยสำคัญที่ต้องตรวจสอบจึงมักเป็นซ็อกเก็ตcockpit.socketไม่ใช่เว็บเซอร์วิสที่ทำงานอย่างต่อcockpit.serviceเนื่อง
sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'
มองหาซ็อกเก็ตที่ทำงาน/กำลังรับฟัง และตัวรับฟังที่ผูกกับพอร์ต 9090 หากไม่มีหน่วยดังกล่าว อาจเป็นเพราะไม่ได้ติดตั้ง Cockpit ในเวอร์ชัน SLES ที่มีที่เก็บซอฟต์แวร์ที่เปิดใช้งานซึ่งมีรูปแบบ Cockpit นั้น SUSE ได้ระบุวิธีการติดตั้งไว้ดังนี้:
sudo zypper refresh
sudo zypper in -t pattern cockpit
หาก Zypper แจ้งว่าไม่พบรูปแบบ ให้ตรวจสอบผลิตภัณฑ์ แพ็คเกจบริการ โมดูลที่เปิดใช้งาน สถานะของที่เก็บ และสิทธิ์การสนับสนุนกับผู้ดูแลระบบ SUSE ของคุณ อย่าเพิ่มที่เก็บของบุคคลที่สามที่ไม่เกี่ยวข้องเพียงเพื่อให้คำสั่งทำงานสำเร็จ หลังจากยืนยันว่าติดตั้ง Cockpit แล้ว ให้เปิดใช้งานและเริ่มต้นซ็อกเก็ต:
sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket
ตัวเลือก นี้--nowจะเริ่มต้นซ็อกเก็ตทันทีและเปิดใช้งานสำหรับการบูตครั้งต่อไป หาก systemd รายงานว่าหน่วยทำงานล้มเหลว ให้ตรวจสอบข้อผิดพลาดที่เกิดขึ้นอย่างละเอียดก่อนที่จะรีสตาร์ทซ้ำๆ:
sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager
3. อนุญาตให้ Cockpit ผ่านโซนไฟร์วอลล์ที่ใช้งานอยู่
แม้ว่าเครื่องรับฟังที่ใช้งานอยู่จะยังคงเข้าถึงไม่ได้หากไฟร์วอลล์ของโฮสต์ตัดการเชื่อมต่อ SLES ใช้ firewalld สำหรับการจัดการไฟร์วอลล์ในเวอร์ชันปัจจุบัน ขั้นแรกให้ระบุโซนที่ใช้งานอยู่และอินเทอร์เฟซที่กำหนดให้กับโซนนั้น:
sudo firewall-cmd --get-active-zones
จากนั้นเพิ่มบริการ Cockpit ที่ตั้งชื่อไว้ลงในโซนที่มีอินเทอร์เฟซการจัดการ แทนที่publicด้วยชื่อโซนจริงที่แสดงบนโฮสต์ของคุณ:
sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit
คำสั่งสุดท้ายควรรายงานผลลัพธ์yesหากอินเทอร์เฟซเครือข่ายอยู่ในโซนอื่น การเปิดบริการในโซนpublicนั้นจะไม่แก้ไขกฎของอินเทอร์เฟซนั้น เอกสาร Cockpit ของ SUSE ใช้cockpitบริการ firewalld การเปิดบริการที่ระบุชื่อนั้นดีกว่าการเปิดการรับส่งข้อมูลทั้งหมดหรือการปิดใช้งานไฟร์วอลล์ นอกจากนี้ ให้ตรวจสอบกลุ่มความปลอดภัยบนคลาวด์ ไฟร์วอลล์รอบนอก นโยบาย VPN และ ACL เครือข่าย หากกฎของโฮสต์ถูกต้อง แต่ไคลเอ็นต์ยังคงหมดเวลา
หากอิมเมจ SLES ของคุณใช้การตั้งค่าการจัดการไฟร์วอลล์ที่แตกต่างออกไป ให้ปฏิบัติตามนโยบายของระบบนั้นแทนที่จะใช้คำสั่ง firewalld โดยไม่คิดไตร่ตรอง อย่าล้างกฎไฟร์วอลล์หรือปิดใช้งานไฟร์วอลล์บนเซิร์ฟเวอร์การผลิตที่จัดการจากระยะไกล: การกระทำดังกล่าวอาจทำให้บริการต่างๆ ตกอยู่ในความเสี่ยงและอาจขัดขวางเส้นทางการจัดการปัจจุบันของคุณได้
4. แยกแยะปัญหาการเชื่อมต่อล้มเหลวออกจากปัญหาเกี่ยวกับใบรับรองหรือการเข้าสู่ระบบ
เมื่อหน้าเข้าสู่ระบบโหลดเสร็จแล้ว แสดงว่าการเชื่อมต่อเครือข่ายไปยัง Cockpit ทำงานได้แล้ว โดยปกติ Cockpit จะคาดหวังว่าการเชื่อมต่อจากเบราว์เซอร์จะใช้ HTTPS และจะแสดงใบรับรอง TLS คำเตือนเกี่ยวกับใบรับรองที่ลงนามด้วยตนเองหรือชื่อไม่ตรงกันไม่ได้หมายความว่าซ็อกเก็ตล้มเหลว สำหรับโฮสต์ในห้องปฏิบัติการ ให้ตรวจสอบลายนิ้วมือผ่านช่องทางที่เชื่อถือได้ก่อนที่จะยอมรับคำเตือน สำหรับระบบที่ได้รับการจัดการ ให้ติดตั้งใบรับรองที่มีชื่อเรื่องตรงกับชื่อโฮสต์ที่ผู้ดูแลระบบใช้ และห่วงโซ่ใบรับรองนั้นได้รับความไว้วางใจจากเบราว์เซอร์ของพวกเขา
หากหน้าเข้าสู่ระบบปรากฏขึ้น แต่ข้อมูลประจำตัวถูกปฏิเสธ ให้ตรวจสอบชื่อผู้ใช้ รหัสผ่าน สถานะบัญชี และนโยบายการตรวจสอบสิทธิ์ของเซิร์ฟเวอร์ โดยทั่วไป Cockpit จะตรวจสอบสิทธิ์กับบัญชีระบบ ไม่ใช่ฐานข้อมูลผู้ใช้แยกต่างหาก อย่าใส่รหัสผ่านในคำสั่งหรือบันทึกขณะแก้ไขปัญหา หากหน้าเว็บโหลดได้ แต่หน้าจอแสดงผลว่างเปล่าหรือตัดการเชื่อมต่อหลังจากเข้าสู่ระบบ ให้ตรวจสอบคอนโซลสำหรับนักพัฒนาของเบราว์เซอร์และบันทึก Cockpit ล่าสุด พร็อกซีแบบย้อนกลับอาจทำให้เกิดความล้มเหลวได้เช่นกัน หากไม่รองรับการเชื่อมต่อ WebSocket หรือส่งต่อโปรโตคอลหรือข้อมูลโฮสต์ที่ไม่ถูกต้อง
5. ตรวจสอบบันทึกและตั้งค่าพร็อกซีเมื่อผ่านขั้นตอนพื้นฐานแล้ว
บันทึกข้อมูลช่วงเวลาสั้นๆ ขณะพยายามเชื่อมต่อใหม่หนึ่งครั้ง:
sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager
ตรวจสอบหาข้อผิดพลาดในการเชื่อมต่อ ข้อผิดพลาดด้านสิทธิ์หรือใบรับรอง และข้อความที่ตรงกับเวลาทดสอบ หากเซิร์ฟเวอร์รับฟังการเชื่อมต่อในเครื่องได้ แต่ไคลเอนต์ระยะไกลไม่สามารถเชื่อมต่อได้ ให้ตรวจสอบเส้นทางเครือข่ายและโซน firewalld ก่อนที่จะเปลี่ยนแปลงการกำหนดค่า Cockpit หากการเข้าถึงโดยตรงใช้งานได้ แต่การเข้าถึงผ่านพร็อกซีล้มเหลว ให้ลองเปรียบเทียบผ่านเส้นทางโดยตรงที่ได้รับอนุญาตชั่วคราว จากนั้นตรวจสอบการสนับสนุนการอัปเกรด WebSocket และส่วนหัวที่ส่งต่อของพร็อกซี หลีกเลี่ยงการเปลี่ยนแปลงการตั้งค่าต้นทางหรือ TLS ของ Cockpit ในขั้นตอนแรก การตั้งค่าความเชื่อถือพร็อกซีที่ไม่ถูกต้องอาจทำให้ความปลอดภัยลดลง
ตรวจสอบการซ่อมแซม
หลังจากทำการเปลี่ยนแปลงทีละอย่างแล้ว โปรดตรวจสอบผลลัพธ์เหล่านี้:
systemctl status cockpit.socketแสดงว่าซ็อกเก็ตทำงานและพร้อมรับฟัง
- โฮสต์ SLES มีตัวรับฟังอยู่ที่พอร์ตที่คาดไว้ ซึ่งโดยปกติคือ TCP 9090
- กฎไฟร์วอลล์อยู่ในโซนที่กำหนดให้กับอินเทอร์เฟซการจัดการ
- ลูกค้าสามารถเข้าถึงเซิร์ฟเวอร์ได้ที่
https://SERVER_IP:9090และเห็นหน้าเข้าสู่ระบบ Cockpit
- หลังจากยืนยันตัวตนแล้ว หน้าเว็บจะยังคงเชื่อมต่ออยู่ และบันทึกการทำงานล่าสุดไม่มีข้อผิดพลาดในการเริ่มต้นหรือการเชื่อมต่อใดๆ ที่ตรงกัน
หากซ็อกเก็ตทำงานอยู่และการตรวจสอบภายในสำเร็จ แต่การทดสอบ TCP ระยะไกลยังคงหมดเวลา ความผิดพลาดที่เหลืออยู่มักจะอยู่นอก Cockpit เอง เช่น ไฟร์วอลล์ต้นทาง เส้นทางเครือข่าย บันทึก DNS หรือกฎ VPN หากบริการล้มเหลวในระบบ SLES ที่ได้รับการสนับสนุน ให้บันทึกสถานะของหน่วยและเอาต์พุตบันทึก และตรวจสอบเอกสาร SUSE หรือช่องทางการสนับสนุนสำหรับการกำหนดค่า Service Pack ที่ถูกต้อง แทนที่จะใช้การแก้ไขที่ออกแบบมาสำหรับระบบปฏิบัติการอื่น
เอกสารอ้างอิงอย่างเป็นทางการ