เลือกใช้ Cockpit หรือ Webmin จัดการ VPS ตัวไหนดีกว่ากัน

Cockpit กับ Webmin: คำตอบโดยสรุป

Cockpit และ Webmin ต่างเป็นเว็บพาเนลสำหรับจัดการเซิร์ฟเวอร์ Linux ผ่านเบราว์เซอร์ โดยทั้งสองเครื่องมือมีจุดประสงค์การใช้งานที่แตกต่างกัน Cockpit มาพร้อมกับ repository ของ distribution ที่คุณใช้งานและอ่านค่าสถานะของเครื่องผ่าน systemd, journald, polkit และ udisks ทำให้คุณยังคงจัดการเซิร์ฟเวอร์ผ่าน SSH ได้ตามปกติ ส่วน Webmin มีอายุการใช้งานที่ยาวนานกว่าและครอบคลุมการทำงานที่กว้างขวางกว่ามาก โดย Webmin จะเขียนไฟล์คอนฟิกูเรชันสำหรับ Apache, BIND, Postfix, MariaDB และบริการอื่นๆ อีกหลายสิบรายการที่ Cockpit ไม่ได้เข้าไปยุ่งเกี่ยว อีกทั้งยังรันเว็บเซิร์ฟเวอร์ของตนเองในฐานะ root เพื่อดำเนินการดังกล่าว

ให้ติดตั้ง Cockpit เมื่อคุณต้องการดูสถานะแบบเรียลไทม์ของเซิร์ฟเวอร์หนึ่งเครื่อง, ต้องการอ่าน log และต้องการ terminal สำหรับกรณีฉุกเฉิน ให้ติดตั้ง Webmin เมื่อคุณต้องการเครื่องมือแก้ไขแบบฟอร์มสำหรับบริการที่คุณไม่ต้องการตั้งค่าด้วยตนเอง ห้ามเปิดใช้งานทั้งสองเครื่องมือบนพอร์ตสาธารณะโดยใช้การล็อกอินด้วยรหัสผ่าน หากคุณดูแลเซิร์ฟเวอร์มากกว่า 2 หรือ 3 เครื่อง คำตอบที่ตรงไปตรงมาที่สุดคือไม่ควรใช้ทั้งสองอย่าง เพราะการใช้ SSH ร่วมกับ Ansible จะสามารถขยายขีดความสามารถในการจัดการได้ดีกว่าการใช้พาเนลใดๆ

สิ่งที่แต่ละพาเนลสามารถเปลี่ยนแปลงได้จริง

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

• บริการและตัวตั้งเวลาของ systemd: เริ่ม, หยุด, เปิดใช้งาน และอ่านไฟล์ unit
• บันทึก journal ที่กรองตาม unit และระดับความสำคัญ ซึ่งมาพร้อมกับ journalctl ที่มีตัวเลือกวันที่
• บัญชีผู้ใช้ภายในเครื่อง, การเป็นสมาชิกกลุ่ม และกุญแจ SSH ที่ได้รับอนุญาต
• การจัดการพื้นที่จัดเก็บข้อมูลด้วย cockpit-storaged: พาร์ทิชัน, LVM volume group, ระบบไฟล์ และจุดเชื่อมต่อ (mount point)
• คอนเทนเนอร์ด้วย cockpit-podman ซึ่งจัดการเฉพาะ Podman เท่านั้น
• การอัปเดตแพ็กเกจด้วย cockpit-packagekit
• กราฟแสดง CPU, หน่วยความจำ, ดิสก์ และเครือข่ายด้วย cockpit-pcp
• เทอร์มินัลระดับ root ในแท็บเบราว์เซอร์

มีสองส่วนที่ดูเหมือนใช้งานไม่ได้บน Ubuntu VPS แต่จริงๆ แล้วไม่ใช่ปัญหา Cockpit หน้า Networking เป็นส่วนติดต่อสำหรับ NetworkManager แต่ Ubuntu server ใช้ netplan ร่วมกับ systemd-networkd หน้าดังกล่าวจึงหายไปหรือว่างเปล่า ห้ามติดตั้ง NetworkManager บนเซิร์ฟเวอร์ระยะไกลเพื่อให้หน้าจอนี้กลับมา เพราะมันจะเข้าควบคุมอินเทอร์เฟซเครือข่าย และหากเกิดข้อผิดพลาด คุณอาจสูญเสียการเชื่อมต่อ SSH ไปด้วย ส่วนการควบคุมไฟร์วอลล์ของ Cockpit เป็นส่วนติดต่อสำหรับ firewalld แต่ Ubuntu ใช้ ufw คุณจึงไม่สามารถควบคุมไฟร์วอลล์ผ่านหน้าจอนี้ได้ คุณควรใช้งาน sudo ufw status ผ่านเทอร์มินัลต่อไป

Webmin ครอบคลุมการทำงานที่กว้างขวางกว่ามาก เนื่องจากเป็นชุดของโมดูลแยกตามบริการ แทนที่จะเป็นโปรแกรมเดียว:

• การตั้งค่า Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL และ Samba ผ่านแบบฟอร์ม
• การจัดการผู้ใช้, กลุ่ม และโควตาพื้นที่ดิสก์
• งาน cron และนาฬิกาของระบบ
• การอัปเดตแพ็กเกจ รวมถึงตัวจัดการไฟล์ที่รองรับการอัปโหลดและดาวน์โหลด
• ส่วนติดต่อสำหรับไฟร์วอลล์ รวมถึงโมดูลสำหรับ iptables และ firewalld
• การสำรองไฟล์คอนฟิกูเรชัน และโมดูลคลัสเตอร์ที่ส่งการเปลี่ยนแปลงไปยังเซิร์ฟเวอร์ Webmin อื่นๆ

Webmin แก้ไขไฟล์จริงภายใต้ /etc ไม่มีฐานข้อมูลซ่อนอยู่เบื้องหลังแบบฟอร์ม ดังนั้นหาก /etc อยู่ภายใต้การควบคุมเวอร์ชัน การใช้ sudo git -C /etc diff หลังจากบันทึกแบบฟอร์มจะแสดงให้เห็นสิ่งที่โมดูลเขียนลงไปอย่างชัดเจน นั่นเป็นวิธีที่เร็วที่สุดในการเรียนรู้ว่าหน้าเว็บของ Webmin แต่ละหน้าทำงานอย่างไร คำแนะนำการติดตั้งและการเข้าสู่ระบบครั้งแรกของ Webmin จะอธิบายโครงสร้างโมดูลโดยละเอียด Virtualmin และ Usermin เป็นผลิตภัณฑ์แยกต่างหากที่สร้างบนเอนจินเดียวกัน สำหรับการโฮสต์ร่วมและการใช้งานของผู้ใช้ทั่วไป ซึ่งได้รับคุณสมบัติทั้งหมดที่กล่าวมาข้างต้นในแง่ของการเปิดเผยข้อมูลระบบ

วิธีการตรวจสอบสิทธิ์ของแต่ละตัว

Cockpit ไม่มีฐานข้อมูลผู้ใช้เป็นของตนเอง หน้าล็อกอินของ Cockpit จะรัน stack ของ PAM (pluggable authentication modules) ใน /etc/pam.d/cockpit ดังนั้นบัญชีผู้ใช้และรหัสผ่านจึงเป็นชุดเดียวกับบัญชี Unix ของคุณ โดยค่าเริ่มต้นระบบจะปฏิเสธการล็อกอินด้วย root เนื่องจากมีชื่ออยู่ใน /etc/cockpit/disallowed-users การดำเนินการที่ต้องใช้สิทธิ์ระดับสูงจะผ่าน polkit และอินเทอร์เฟซจะขอรหัสผ่านของคุณอีกครั้งก่อนที่จะทำการเปลี่ยนแปลงใดๆ นี่คือเหตุผลที่ส่วนหัวของหน้าเว็บอาจแสดงสถานะ "Limited access" จนกว่าคุณจะยกระดับสิทธิ์

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

sudo passwd -S deploy

หากผลลัพธ์ขึ้นต้นด้วย deploy L หมายความว่ารหัสผ่านถูกล็อกไว้ ทำให้ PAM ไม่มีข้อมูลให้ตรวจสอบสิทธิ์และรหัสผ่านที่คุณพิมพ์จะไม่สามารถใช้งานได้ ส่วน P หมายความว่ามีการตั้งรหัสผ่านที่ใช้งานได้ไว้แล้ว หน้าล็อกอินของ Cockpit เองไม่รองรับการใช้ SSH keys โดยคีย์จะถูกใช้ก็ต่อเมื่อ Cockpit เชื่อมต่อไปยังโฮสต์อื่นจากเครื่องที่คุณล็อกอินอยู่เท่านั้น

Webmin เก็บข้อมูลผู้ใช้ของตนเองไว้ใน /etc/webmin/miniserv.users ซึ่งแยกจาก /etc/passwd และยังสามารถตั้งค่าให้ตรวจสอบสิทธิ์เทียบกับบัญชี Unix ได้อีกด้วย ผู้ใช้ Webmin ที่ได้รับสิทธิ์เข้าถึงทุกโมดูลจะมีสถานะเป็น root บนเครื่องนั้นโดยไม่คำนึงถึง login shell ที่ตั้งไว้ Webmin มาพร้อมกับการรองรับ TOTP (time-based one-time password) และระบบบล็อกโฮสต์หลังจากล็อกอินล้มเหลวหลายครั้ง ซึ่งทั้งสองอย่างนี้สามารถเปิดใช้งานได้ภายใน Webmin Configuration สำหรับ Cockpit นั้น การเพิ่มปัจจัยที่สอง (second factor) จะทำได้ก็ต่อเมื่อคุณเพิ่มเข้าไปใน PAM เท่านั้น เช่น การใช้ libpam-google-authenticator

วิธีการอัปเดตแต่ละตัว

Cockpit ถูกจัดทำเป็นแพ็กเกจโดย distribution ของคุณ บน Ubuntu 24.04 จะมาจากคลังซอฟต์แวร์หลัก และโครงการต้นทางแนะนำให้ใช้ backports pocket เพื่อรับรุ่นที่ใหม่กว่า:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy จะแสดงเวอร์ชันที่คุณติดตั้งและคลังซอฟต์แวร์ต้นทาง หากใน backports ไม่มีรุ่นที่ใหม่กว่า apt จะถอยกลับไปใช้เวอร์ชันจากคลังหลักซึ่งถือว่าใช้งานได้ตามปกติ cockpit.socket ควรแสดงผลเป็น active (listening) การแก้ไขด้านความปลอดภัยจะเข้ามาผ่านการรัน unattended-upgrades เดียวกันกับ kernel ของคุณ จากผู้เผยแพร่ที่คุณเชื่อถืออยู่แล้ว

Webmin ไม่ได้อยู่ในคลังซอฟต์แวร์ของ Ubuntu การติดตั้งอย่างเป็นทางการต้องเพิ่มคลังซอฟต์แวร์และ signing key ของ Webmin เองก่อน:

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

โปรดอ่านสคริปต์นั้นก่อนรัน เพราะสคริปต์ทำงานด้วยสิทธิ์ root หลังจากนั้นทุกการรัน apt upgrade บนเซิร์ฟเวอร์จะดึงข้อมูลจากคลังซอฟต์แวร์ของ Webmin ด้วยเช่นกัน เท่ากับว่าคุณได้เพิ่มผู้เผยแพร่รายที่สองที่มีสิทธิ์ระดับ root บนเครื่องของคุณ นี่คือต้นทุนที่แท้จริงของ Webmin ซึ่งมีตัวอย่างที่ชัดเจนคือ CVE-2019-15107 ซึ่งเป็น backdoor ในแพ็กเกจรุ่น 1.9x หลายตัวที่เปิดช่องให้รันคำสั่งได้โดยไม่ต้องยืนยันตัวตน และมันเข้าถึงผู้ใช้ได้เพราะโฮสต์ที่ใช้ build ของโครงการถูกเจาะระบบ ไม่ใช่ที่ตัว source repository การทำ packaging โดย distribution ไม่ได้ทำให้เหตุการณ์นี้เป็นไปไม่ได้ แต่เป็นการเพิ่มขั้นตอนการ build และการตรวจสอบที่คุณไม่ต้องดูแลด้วยตัวเอง

เหตุผลที่ไม่ควรเปิดพอร์ตสาธารณะสำหรับทั้งสองบริการ

Cockpit ทำงานบน TCP 9090 และ Webmin บน TCP 10000 โดยทั้งคู่ใช้ TLS (transport layer security) พร้อมใบรับรองแบบ self-signed ทำให้สิ่งแรกที่คุณพบคือคำเตือนจากเบราว์เซอร์ การสร้างและเชื่อถือใบรับรองแบบ self-signed อธิบายว่าคำเตือนนั้นบอกอะไรและไม่บอกอะไรแก่คุณ พอร์ตทั้งสองถูกสแกนอยู่ตลอดเวลา และแผงควบคุมทั้งสองมีสิทธิ์ระดับ root ดังนั้นหากรหัสผ่านถูกเดาได้หรือถูกนำไปใช้ซ้ำ จะส่งผลให้เซิร์ฟเวอร์ถูกบุกรุกโดยสมบูรณ์

รูปแบบที่ปลอดภัยคือการผูกแผงควบคุมไว้กับ localhost และเข้าถึงผ่าน SSH tunnel สำหรับ Cockpit ให้ทำการ override socket unit ดังนี้:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

จำเป็นต้องมี ListenStream= ว่างเปล่าในบรรทัดของตัวเอง เนื่องจาก systemd จะผนวกค่าเข้ากับรายการตั้งค่าเดิม หากไม่มีบรรทัดนี้ unit จะยังคงค่า 0.0.0.0:9090 เดิมไว้และเพิ่ม address ใหม่เข้าไป ทำให้แผงควบคุมของคุณยังคงเป็นสาธารณะอยู่ ให้ใช้การ override และตรวจสอบว่าพอร์ตใดกำลังทำงานอยู่:

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

ผลลัพธ์ต้องแสดง 127.0.0.1:9090 หากเป็น address *:9090 หรือ 0.0.0.0:9090 แสดงว่าการ override ไม่มีผล จากนั้นให้เปิด tunnel จากเครื่องของคุณและเข้าถึงผ่านเบราว์เซอร์ที่ https://localhost:9090:

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

ให้กำหนดพอร์ต local ให้ตรงกับพอร์ต remote Cockpit จะเปรียบเทียบ header Origin ของเบราว์เซอร์กับ address ที่มันเข้าใจว่ากำลังให้บริการอยู่ ดังนั้นการทำ tunnel จากพอร์ต local 9999 จะโหลดหน้า login ได้แต่จะล้มเหลวเมื่อกดเข้าสู่ระบบ และ journalctl -u cockpit จะบันทึก origin ที่ถูกปฏิเสธไว้ หากคุณต้องการใช้พอร์ต local อื่น ให้ระบุใน /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

รีสตาร์ทด้วย sudo systemctl restart cockpit.socket เพื่อให้การตั้งค่ามีผล สำหรับ Webmin การตั้งค่าที่เทียบเท่ากันจะอยู่ใน /etc/webmin/miniserv.conf:

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin จะตรวจสอบ header Referer ในการส่งฟอร์มด้วย และจะปฏิเสธคำขอที่ดูเหมือนมาจาก host อื่น ซึ่งเป็นสาเหตุที่ทำให้การตั้งค่า reverse proxy ในครั้งแรกไม่สำเร็จ บรรทัด referers= ในไฟล์เดียวกันคือจุดที่คุณต้องอนุญาต hostname ของ proxy และ webprefix= คือจุดที่คุณระบุให้ Webmin ทราบว่ามันทำงานอยู่ภายใต้ path ใด

อีกทางเลือกหนึ่งคือการใช้ reverse proxy ที่มีการยืนยันตัวตน: โดยใช้ nginx อยู่ด้านหน้า และมี ชั้นการยืนยันตัวตนแบบ single sign-on ของ Authentik ทำหน้าที่จัดการการ login วิธีนี้ใช้งานได้และเป็นทางเลือกที่ดีรองลงมา แต่แผงควบคุมยังคงทำงานในฐานะ root หลัง proxy และคุณต้องดูแลประตูหน้าถึงสองจุดแทนที่จะเป็นจุดเดียว การใช้ tunnel จะไม่เพิ่มบริการที่เปิดรับการเชื่อมต่อจากอินเทอร์เน็ตเลย และยังเป็นการใช้ SSH key ที่คุณปกป้องไว้อยู่แล้วซ้ำให้เกิดประโยชน์

แผงควบคุมใดที่ควรใช้บนเซิร์ฟเวอร์ที่รันบริการสำหรับใช้งานจริงอยู่แล้ว

ควรเลือกใช้ Cockpit ด้วยเหตุผล 2 ประการที่สำคัญเมื่อมีผู้อื่นต้องพึ่งพาเครื่องเซิร์ฟเวอร์นี้ ประการแรก Cockpit ทำงานแบบ socket activated หมายความว่า cockpit-ws จะทำงานเฉพาะในขณะที่มี session เปิดอยู่เท่านั้น และไม่มี root daemon ถาวรคอยรอรับการเชื่อมต่ออยู่ที่พอร์ตใดๆ ประการที่สอง Cockpit ไม่ได้เป็นเจ้าของส่วนประกอบใดๆ ในระบบ หากคุณลบแพ็กเกจออก บริการทุกอย่างจะยังคงทำงานได้ตามปกติเหมือนเดิม เนื่องจาก Cockpit ไม่ได้จัดเก็บการตั้งค่าใดๆ ของตนเองไว้ ในขณะที่ miniserv.pl ของ Webmin จะทำงานค้างอยู่ในหน่วยความจำตลอดเวลาไม่ว่าจะมีใครล็อกอินอยู่หรือไม่ก็ตาม คุณสามารถตรวจสอบการใช้ทรัพยากรของเครื่องคุณได้ด้วยคำสั่ง systemctl status webmin ซึ่งจะแสดงค่าหน่วยความจำที่กระบวนการนั้นๆ ใช้งานอยู่

หากคุณจำเป็นต้องใช้โมดูล DNS หรืออีเมลของ Webmin ควรแยกเซิร์ฟเวอร์สำหรับงานดังกล่าวโดยเฉพาะ การใช้ Webmin บนเซิร์ฟเวอร์ที่ทำหน้าที่เพียงอย่างเดียวและจำกัดการเข้าถึงไว้ที่ 127.0.0.1 จะช่วยจำกัดความเสี่ยงให้อยู่ในวงจำกัด แต่การใช้ Webmin บนโฮสต์เดียวกันกับแอปพลิเคชันที่ให้บริการลูกค้าถือเป็นความเสี่ยงที่ไม่ควรทำ ควรดำเนินการตั้งค่าพื้นฐานให้เรียบร้อยก่อนติดตั้งแผงควบคุมใดๆ โดยสามารถดูรายละเอียดได้ที่ สิบนาทีแรกบน VPS ใหม่ ซึ่งครอบคลุมถึงการสร้างผู้ใช้ที่ไม่ใช่ root และการตั้งค่าไฟร์วอลล์ที่แผงควบคุมทั้งสองแบบถือว่าเป็นสิ่งที่ต้องมีอยู่แล้วในระบบ

เมื่อคำตอบไม่ใช่ทั้งสองอย่าง

แผงควบคุม (panel) เป็นเครื่องมือที่ใช้งานแบบรายเซิร์ฟเวอร์และต้องทำด้วยตนเอง อีกทั้งยังไม่ทิ้งบันทึกว่ามีการเปลี่ยนแปลงอะไรหรือเพราะเหตุใด ซึ่งอาจเพียงพอสำหรับเซิร์ฟเวอร์เครื่องเดียว แต่เมื่อมี 5 เครื่อง คุณจะต้องทำซ้ำงานเดิม และเมื่อถึง 20 เครื่อง คุณจะเริ่มเดาไม่ออกว่าเซิร์ฟเวอร์เครื่องไหนที่ยังไม่ได้ปรับปรุงการตั้งค่า แม้ว่า Cockpit จะสามารถเพิ่มโฮสต์อื่นเข้ามาในเซสชันเดียวผ่าน SSH ได้ แต่เวอร์ชันใหม่ๆ ได้ปิดการใช้งานนี้ไว้เป็นค่าเริ่มต้นและต้องการ AllowMultiHost=yes ใน /etc/cockpit/cockpit.conf นอกจากนี้คุณยังคงต้องคลิกเพื่อตั้งค่าเดิมซ้ำถึง 5 ครั้งอยู่ดี

ทางเลือกอื่นคือการใช้ SSH ปกติร่วมกับการเก็บไฟล์ตั้งค่าไว้ใน git repository บทความ การจัดการเซิร์ฟเวอร์ Linux หลายเครื่องจากจุดเดียว ได้อธิบายรูปแบบการตั้งค่าดังกล่าวไว้ และ Ansible playbook แรกของคุณ จะช่วยให้คุณใช้กฎ firewall เดียวกันกับทุกโฮสต์ได้จากไฟล์เดียวที่คุณสามารถตรวจสอบความเปลี่ยนแปลงผ่าน diff ได้ สำหรับงานด้านคอนเทนเนอร์ก็ใช้หลักการเดียวกัน คือการใช้ docker compose up -d ผ่าน SSH จากไฟล์ที่เก็บใน git ดังที่ระบุไว้ใน คู่มือพื้นฐาน Docker Compose ซึ่งดีกว่าการคลิกผ่านแผงควบคุมใดๆ อีกทั้ง Cockpit เองก็ไม่ได้ถูกออกแบบมาเพื่อจัดการ Docker ตั้งแต่แรก

ให้ใช้แผงควบคุมสำหรับงานที่ terminal ทำได้ไม่ดี เช่น การอ่านกราฟตัวชี้วัด (metrics) หรือการตรวจสอบว่าหน่วยบริการ (unit) ใดใน 40 หน่วยที่ทำงานล้มเหลว และให้ใช้โค้ดสำหรับงานใดก็ตามที่คุณต้องทำมากกว่าสองครั้งขึ้นไป

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

Cockpit ปฏิเสธรหัสผ่านที่ SSH ยอมรับ บัญชีดังกล่าวถูกตั้งค่าให้ใช้เฉพาะคีย์เท่านั้น sudo passwd -S alice จะแสดง L ในฟิลด์ที่สอง ทำให้ PAM ไม่มีรหัสผ่านสำหรับตรวจสอบ ให้ตั้งรหัสผ่านด้วย sudo passwd alice หรือใช้บัญชีนั้นสำหรับ SSH ต่อไป และล็อกอินเข้า Cockpit ด้วยผู้ใช้อื่นแทน

Cockpit ปฏิเสธสิทธิ์ root แม้จะใช้รหัสผ่านที่ถูกต้อง /etc/cockpit/disallowed-users จะแสดงรายการ root ให้ล็อกอินด้วยผู้ใช้ปกติที่มีสิทธิ์ sudo นี่คือแนวทางที่ออกแบบไว้ เนื่องจาก polkit จะบันทึกว่าบุคคลใดเป็นผู้ยกระดับสิทธิ์

Cockpit ไม่แสดงหน้า Networking หรือ Firewall หน้าเหล่านี้ต้องการ NetworkManager และ firewalld ในขณะที่ Ubuntu VPS ใช้ netplan ร่วมกับ systemd-networkd และ ufw หน้าดังกล่าวจึงไม่ปรากฏขึ้น ไม่ได้มีส่วนใดเสียหาย วิธีแก้ไขคือให้ใช้งาน ufw ผ่าน SSH ต่อไป

หน้าล็อกอินของ Cockpit โหลดผ่าน tunnel ได้ แต่ล็อกอินไม่สำเร็จ พอร์ตในเครื่องของคุณไม่ตรงกับพอร์ตที่ฝั่งรีโมท ทำให้การตรวจสอบ Origin ล้มเหลวและ journalctl -u cockpit จะแสดงข้อความแจ้งเตือน ให้ตั้งค่าพอร์ตให้ตรงกัน หรือกำหนด Origins ใน /etc/cockpit/cockpit.conf

การส่งฟอร์มของ Webmin ล้มเหลวหลังจากนำไปไว้หลัง proxy การตรวจสอบ Referer จะปฏิเสธการส่งข้อมูลดังกล่าว ให้เพิ่มชื่อโฮสต์ของ proxy ลงใน referers= ในไฟล์ /etc/webmin/miniserv.conf และตั้งค่า webprefix= เมื่อมีการให้บริการแผงควบคุมผ่าน path

คุณไม่แน่ใจว่าแผงควบคุมถูกเปิดเผยสู่สาธารณะหรือไม่ sudo ss -lntp | grep -E '9090|10000' จะให้คำตอบจากตัวเซิร์ฟเวอร์เอง และ Webmin จะบันทึกความพยายามล็อกอินทุกครั้งลงใน /var/webmin/miniserv.log ซึ่งควรตรวจสอบอย่างน้อยหนึ่งครั้งหลังจากมีการเปลี่ยนแปลงวิธีการรับฟังการเชื่อมต่อของระบบ

FAQ

ระหว่าง Cockpit กับ Webmin ตัวไหนดีกว่าสำหรับ Ubuntu VPS เครื่องเดียว?

สำหรับผู้ใช้ส่วนใหญ่ Cockpit ดีกว่า เนื่องจากติดตั้งผ่าน repository ของ Ubuntu โดยตรง ได้รับการแพตช์พร้อมกับระบบ และทำงานเฉพาะช่วงที่มีการเปิด session ผ่านเบราว์เซอร์เท่านั้น ให้เลือกใช้ Webmin เมื่อคุณต้องการเครื่องมือแก้ไขแบบฟอร์มสำหรับบริการที่ Cockpit ไม่รองรับ เช่น BIND หรือ Postfix โดยต้องยอมรับว่าเว็บเซิร์ฟเวอร์ของ Webmin จะทำงานด้วยสิทธิ์ root ตลอดเวลาและต้องอัปเดตผ่าน repository ของ Webmin เอง

ฉันสามารถรัน Cockpit และ Webmin บนเซิร์ฟเวอร์เดียวกันได้หรือไม่?

ได้ ทั้งสองตัวใช้พอร์ตคนละพอร์ตคือ 9090 และ 10000 จึงไม่เกิดความขัดแย้งกันเนื่องจากต่างฝ่ายต่างแก้ไขระบบโดยตรงแทนที่จะเป็นเจ้าของระบบ อย่างไรก็ตาม นี่ไม่ใช่แนวทางที่ดีนัก เนื่องจากแผงควบคุมแต่ละตัวเป็นช่องทางล็อกอินที่มีสิทธิ์ root แยกกันบนเครื่องเดียวกัน ทำให้คุณเพิ่มความเสี่ยงเป็นสองเท่าเพียงเพื่อแลกกับความสะดวกเพียงเล็กน้อย หากคุณต้องการติดตั้งทั้งสองตัว ให้ผูก (bind) ทั้งคู่ไว้ที่ 127.0.0.1 และเข้าใช้งานผ่าน SSH tunnel

การเปิดพอร์ต 9090 หรือ 10000 สู่สาธารณะปลอดภัยหรือไม่?

ไม่ปลอดภัยหากใช้การล็อกอินด้วยรหัสผ่าน แผงควบคุมทั้งสองตัวนำไปสู่สิทธิ์ root และพอร์ตทั้งสองจะถูกตรวจพบโดยการสแกนอัตโนมัติภายในไม่กี่ชั่วโมงหลังจากเปิดใช้งาน ให้ผูกแผงควบคุมไว้ที่ 127.0.0.1 จากนั้นรัน ssh -N -L 9090:127.0.0.1:9090 user@host แล้วเข้าใช้งานผ่าน https://localhost:9090 ตรวจสอบความถูกต้องด้วย sudo ss -lntp | grep 9090 ซึ่งต้องแสดงผลเป็น 127.0.0.1:9090 แทนที่จะเป็น 0.0.0.0:9090 การใช้ reverse proxy ที่มีการยืนยันตัวตนเป็นทางเลือกที่สองที่ยอมรับได้

ทำไมฉันล็อกอิน Cockpit ไม่ผ่านทั้งที่ SSH ด้วย key ใช้งานได้ปกติ?

Cockpit ยืนยันตัวตนผ่าน PAM ด้วยรหัสผ่าน Unix และหน้าล็อกอินไม่รองรับ SSH keys บนเซิร์ฟเวอร์ที่มีการตั้งค่าความปลอดภัยสูง บัญชีผู้ใช้มักจะไม่มีรหัสผ่านที่ใช้งานได้ ให้รัน sudo passwd -S youruser หากพบ L ในฟิลด์ที่สอง หมายความว่ารหัสผ่านถูกล็อกไว้ ทำให้ PAM ไม่มีรหัสผ่านสำหรับตรวจสอบและปฏิเสธทุกความพยายามในการล็อกอิน ให้ตั้งรหัสผ่านด้วย sudo passwd youruser หรือใช้บัญชีอื่นสำหรับแผงควบคุมนี้

Cockpit จัดการ Docker containers ได้หรือไม่?

ไม่ได้ หน้าจัดการ container ของ Cockpit มาจาก cockpit-podman และใช้สำหรับจัดการ Podman เท่านั้น โมดูล Docker แบบเก่าถูกถอดออกไปหลายปีแล้วและจะไม่มีการนำกลับมา หากบริการของคุณรันอยู่บน Docker ให้จัดการผ่านไฟล์ compose ในระบบ version control ผ่าน SSH และปล่อยให้ Cockpit จัดการระบบส่วนอื่นแทน เช่น journal และ disk