Cockpit أم Webmin لإدارة خادم Ubuntu؟

Cockpit مقابل Webmin: الإجابة المختصرة

Cockpit وWebmin لوحتا ويب لإدارة خادم Linux من المتصفح، لكن لكل منهما هدف مختلف. يأتي Cockpit ضمن مستودع توزيعتك، ويقرأ حالة الجهاز عبر systemd وjournald وpolkit وudisks، لذلك يعرض لك خادماً تواصل إدارته عبر SSH. أما Webmin فهو أقدم وأوسع نطاقاً؛ إذ يكتب ملفات الإعداد الخاصة بـApache وBIND وPostfix وMariaDB وعشرات الخدمات الأخرى التي لا يتعامل معها Cockpit، ويشغّل خادم ويب خاصاً به بحساب root لتنفيذ ذلك.

ثبّت Cockpit عندما تريد عرضاً حياً لخادم واحد، وقارئاً للسجلات، وطرفية للطوارئ. ثبّت Webmin عندما تحتاج إلى محرر قائم على النماذج لخدمة لا تريد إعدادها يدوياً. لا تضع أياً منهما على منفذ عام مع تسجيل دخول يعتمد على كلمة مرور. إذا كنت تدير أكثر من خادمين أو ثلاثة بالفعل، فالإجابة الصريحة غالباً هي عدم استخدام أي منهما؛ إذ يتوسع مسار SSH مع Ansible بصورة أفضل من أي لوحة.

ما الذي يمكن لكل لوحة تغييره فعلياً

تثبيت Cockpit الأساسي صغير، ومعظم المكونات تأتي في حزم منفصلة يمكنك عدم تثبيتها:

• خدمات ومؤقتات systemd: بدء الوحدة وإيقافها وتمكينها وقراءة ملف الوحدة
• journal مع تصفيته حسب الوحدة والأولوية، وهو journalctl مع منتقي تاريخ
• الحسابات المحلية، وعضوية المجموعات، ومفاتيح SSH المصرّح بها
• التخزين باستخدام cockpit-storaged: الأقسام، ومجموعات وحدات LVM، وأنظمة الملفات، ونقاط الربط
• الحاويات باستخدام cockpit-podman، الذي يدير Podman فقط
• تحديثات الحزم باستخدام cockpit-packagekit
• رسوم بيانية للمعالج والذاكرة والقرص والشبكة باستخدام cockpit-pcp
• طرفية root في علامة تبويب المتصفح

تبدو منطقتان معطلتين على VPS يعمل بنظام Ubuntu، لكنهما ليستا كذلك. صفحة Networking في Cockpit هي واجهة أمامية لـNetworkManager، بينما تستخدم صور خوادم Ubuntu ‏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 قاعدة بيانات للمستخدمين. تشغّل صفحة تسجيل الدخول حزمة PAM (وحدات المصادقة القابلة للتوصيل) في /etc/pam.d/cockpit، لذلك تكون الحسابات هي حسابات Unix وتكون كلمات المرور هي كلمات مرور Unix. يُرفض root افتراضياً لأن /etc/cockpit/disallowed-users يدرجه. تمر العمليات ذات الصلاحيات عبر polkit، وتطلب الواجهة كلمة المرور مرة أخرى قبل تغيير أي شيء. لذلك قد يعرض رأس الصفحة عبارة "وصول محدود" إلى أن ترفع مستوى الصلاحيات.

يترتب على هذا التصميم أثر يظهر على الخوادم المقوّاة. إذا اتبعت تسجيل الدخول إلى SSH باستخدام المفاتيح فقط مع تعطيل مصادقة كلمة المرور، فقد لا يملك الحساب كلمة مرور قابلة للاستخدام إطلاقاً. عندها يُرفض تسجيل الدخول إلى Cockpit، بينما يظل ssh يعمل. تحقّق من ذلك على الخادم:

sudo passwd -S deploy

تعني المخرجات التي تبدأ بـ deploy L أن كلمة المرور مقفلة. لذلك لا يملك PAM كلمة مرور يقبلها، ولن تنجح أي كلمة مرور تكتبها. وتعني P أن كلمة مرور قابلة للاستخدام معيّنة. لا تقبل صفحة تسجيل الدخول الخاصة بـ Cockpit مفاتيح SSH. تُستخدم المفاتيح فقط عندما يتصل Cockpit من الجهاز الذي سجّلت الدخول إليه إلى مضيف آخر.

يحتفظ Webmin بمستخدميه في /etc/webmin/miniserv.users، بصورة منفصلة عن /etc/passwd. ويمكن أيضاً إعداده للمصادقة باستخدام حسابات Unix. يكون مستخدم Webmin الذي مُنح جميع الوحدات مستخدماً بصلاحيات root على ذلك الجهاز، بغض النظر عما يحدده غلاف تسجيل الدخول الخاص به. يوفّر Webmin دعماً مدمجاً لـ TOTP (كلمة مرور لمرة واحدة مستندة إلى الوقت)، كما يوفّر آلية خاصة لحظر المضيفين بعد تكرار محاولات تسجيل الدخول الفاشلة. وتُفعّل الميزتان من داخل Webmin Configuration. ولا يحصل Cockpit على عامل مصادقة ثانٍ إلا إذا أضفته إلى PAM، مثلاً باستخدام libpam-google-authenticator.

كيفية تحديث كل منهما

تُوفِّر توزيعتك Cockpit ضمن حزمها. في Ubuntu 24.04 تأتي الحزمة من المستودع، ويوصي المشروع upstream باستخدام مستودع backports للحصول على إصدار أحدث:

. /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. تضيف طريقة التثبيت الرسمية مستودع 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 باباً خلفياً في عدة حزم من الإصدار 1.9x، أتاحت تنفيذ أوامر دون مصادقة. ووصلت إلى المستخدمين لأن خادم بناء المشروع تعرّض للاختراق، وليس لأن مستودع المصدر تعرّض لذلك. لا تجعل حزم التوزيعة هذا الأمر مستحيلاً. لكنها تضيف خطوة بناء ومراجعة لا تحتاج إلى إدارتها بنفسك.

لماذا لا ينبغي تعريض أيٍّ منهما على منفذ عام

يستمع Cockpit على TCP 9090 ويستمع Webmin على TCP 10000، ويستخدم كلاهما TLS (أمان طبقة النقل) مع شهادة موقَّعة ذاتياً، لذلك يكون أول ما تراه هو تحذير في المتصفح. يشرح إنشاء شهادة موقَّعة ذاتياً والوثوق بها ما الذي يخبرك به هذا التحذير وما الذي لا يخبرك به. يتعرّض كلا المنفذين للفحص باستمرار، وتؤدي كلتا لوحتي التحكم إلى root، لذلك يمكن لكلمة مرور مُخمَّنة أو مُعاد استخدامها أن تؤدي إلى اختراق كامل للخادم.

النمط الآمن هو ربط لوحة التحكم بـlocalhost والوصول إليها عبر نفق SSH. بالنسبة إلى Cockpit، تجاوز وحدة socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

السطر الفارغ ListenStream= مطلوب بمفرده. يضيف systemd إعدادات القوائم، لذلك من دونه تحتفظ الوحدة بـ0.0.0.0:9090 الأصلي وتضيف العنوان الجديد، وتظل لوحة التحكم متاحة للعامة. طبّق التجاوز وتحقق مما يستمع:

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

يجب أن يُظهر الناتج 127.0.0.1:9090. يعني العنوان *:9090 أو 0.0.0.0:9090 أن التجاوز لم يُطبَّق. افتح الآن النفق من جهازك وتصفّح إلى https://localhost:9090:

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

أبقِ المنفذ المحلي مساوياً للمنفذ البعيد. يقارن Cockpit ترويسة Origin في المتصفح بالعنوان الذي يعتقد أنه يقدّم الخدمة عليه، لذلك يحمّل نفق من المنفذ المحلي 9999 صفحة تسجيل الدخول ثم يفشل عند تسجيل الدخول، ويسجّل journalctl -u cockpit الأصل المرفوض. إذا احتجت إلى منفذ محلي مختلف، فحدده في /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 أيضاً ترويسة Referer في عمليات إرسال النماذج، ويرفض الطلبات التي تبدو وكأنها قادمة من مضيف آخر، وهذا ما يعطّل المحاولة الأولى لاستخدام reverse proxy. يحدد السطر referers= في الملف نفسه الموضع الذي تسمح فيه باسم مضيف الـproxy، بينما يحدد webprefix= المسار الذي تعمل Webmin تحته.

الخيار الآخر هو reverse proxy يتطلب المصادقة: nginx أمام الخدمة، مع طبقة تسجيل الدخول الموحّد Authentik لإجراء تسجيل الدخول. يعمل هذا الخيار، لكنه يأتي في المرتبة الثانية. تظل لوحة التحكم تعمل بصلاحيات root خلف الـproxy، وتصبح مسؤولاً عن نقطتي دخول بدلاً من نقطة واحدة. لا يضيف النفق أي خدمة تستمع على الإنترنت، كما يعيد استخدام مفتاح SSH الذي تحميه بالفعل.

أي لوحة على خادم يشغّل خدمات إنتاجية بالفعل

اختر Cockpit لسببين مهمين عندما يعتمد أشخاص آخرون على الخادم. يُفعَّل عبر socket، لذلك لا يعمل cockpit-ws إلا أثناء فتح جلسة، ولا يوجد daemon دائم بصلاحيات root ينتظر على منفذ. كما أنّه لا يملك أي شيء: أزل الحزمة، وستواصل كل خدمة العمل تماماً كما كانت، لأن Cockpit لا يخزّن أي إعدادات خاصة به. أمّا miniserv.pl الخاص بـWebmin فيظل مقيماً في الذاكرة سواء سجّل أي شخص الدخول أم لا. تحقّق من استهلاك نسختك باستخدام systemctl status webmin، الذي يطبع الذاكرة المقيمة للعملية قيد التشغيل.

إذا كنت تحتاج إلى وحدات DNS أو البريد في Webmin، فخصّص لها خادماً مستقلاً. يكون خادم Webmin الذي ينفّذ مهمة واحدة، ومربوطاً بـ127.0.0.1، خطراً محصوراً. أمّا تشغيل Webmin على الخادم نفسه الذي يستضيف تطبيقك الموجّه إلى العملاء فليس كذلك. نفّذ الإعداد الأساسي قبل تثبيت أي من اللوحتين: يشرح الـ10 دقائق الأولى على VPS جديد إعداد المستخدم غير root والجدار الناري اللذين تفترض اللوحتان وجودهما مسبقاً.

عندما لا يكون أيٌّ من الخيارين مناسباً

اللوحة خاصة بكل خادم وتتطلب إعداداً يدوياً، ولا تترك سجلاً بما تغيّر أو سبب تغييره. هذا مناسب لخادم واحد. عند استخدام خمسة خوادم، ستكرر الخطوات نفسها، وعند استخدام عشرين خادماً، ستخمن أي خادم لم يتلقَّ التغيير. يمكن لـCockpit إضافة مضيفين آخرين إلى جلسة واحدة عبر SSH، لكن الإصدارات الحديثة تعطل ذلك افتراضياً وتتطلب AllowMultiHost=yes في /etc/cockpit/cockpit.conf، كما أنك ستظل تنقر لتنفيذ التغيير نفسه خمس مرات.

البديل هو استخدام SSH مباشرةً مع وضع إعداداتك في مستودع git. يشرح إدارة عدة خوادم Linux من مكان واحد بنية هذا الإعداد، بينما يطبّق أول playbook في Ansible قاعدة جدار الحماية نفسها على كل مضيف من ملف واحد يمكنك مراجعته على شكل diff. وينطبق الأمر نفسه على العمل مع الحاويات: إن تنفيذ docker compose up -d عبر SSH من ملف في git، كما في دليل أساسيات Docker Compose، أفضل من النقر في أي لوحة، وCockpit لا يدير Docker أصلاً.

استخدم اللوحة في المهام التي تكون الطرفية غير مناسبة لها، مثل قراءة رسم بياني للمقاييس أو تحديد أي وحدة من أصل أربعين وحدة فشلت. استخدم التعليمات البرمجية لأي مهمة ستنفذها أكثر من مرتين.

أنماط الفشل والنصوص التي ستظهر

يرفض 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 عبر النفق، ثم يفشل تسجيل الدخول. يختلف المنفذ المحلي عن المنفذ البعيد، لذلك يفشل التحقق Origin ويعرض journalctl -u cockpit السبب. طابق بين المنفذين، أو اضبط Origins في /etc/cockpit/cockpit.conf.

تفشل عمليات إرسال نماذج Webmin بعد وضعه خلف proxy. يرفضها التحقق Referer. أضف اسم مضيف proxy إلى referers= في /etc/webmin/miniserv.conf، واضبط webprefix= عندما تُعرض لوحة التحكم ضمن مسار.

لست متأكداً مما إذا كانت لوحة التحكم مكشوفة. يجيب sudo ss -lntp | grep -E '9090|10000' عن ذلك من الخادم نفسه، ويسجل Webmin كل محاولة تسجيل دخول في /var/webmin/miniserv.log. من المفيد قراءة هذا السجل مرة واحدة بعد أي تغيير في طريقة الاستماع.

FAQ

هل Cockpit أم Webmin أفضل لخادم Ubuntu VPS واحد؟

بالنسبة إلى معظم المستخدمين، Cockpit أفضل لأنه يأتي من مستودع Ubuntu الرسمي، ويتلقى التحديثات الأمنية مع بقية النظام، ولا يعمل إلا أثناء فتح جلسة في المتصفح. اختر Webmin عندما تحتاج إلى محرر قائم على النماذج لخدمة لا يديرها Cockpit، مثل BIND أو Postfix. في المقابل، يجب أن تقبل بأن خادم الويب الخاص به يعمل بامتيازات root طوال الوقت، وأن تحديثاته تأتي من مستودع Webmin الخاص.

هل يمكنني تشغيل Cockpit وWebmin على الخادم نفسه؟

نعم. يستخدمان منفذين مختلفين، هما 9090 و10000، ولا يحدث بينهما تعارض لأن كلاً منهما يعدّل النظام مباشرة بدلاً من امتلاكه. مع ذلك، فهذا خيار غير جيد. كل لوحة منهما توفر عملية تسجيل دخول منفصلة قادرة على استخدام root على الجهاز نفسه، لذلك تضاعف مساحة التعرض مقابل توفير بضع نقرات. إذا ثبّتَّ اللوحتين، اربط كلتيهما بـ 127.0.0.1، ثم استخدمهما عبر نفق SSH.

هل فتح المنفذ 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 باستخدام مفتاح؟

يصادق Cockpit عبر PAM باستخدام كلمة مرور Unix، ولا تقبل صفحة تسجيل الدخول فيه مفاتيح SSH. في الخادم المقوّى، لا يملك الحساب غالباً كلمة مرور صالحة للاستخدام. شغّل sudo passwd -S youruser: تعني قيمة L في الحقل الثاني أن كلمة المرور مقفلة، لذلك لا يملك PAM كلمة مرور يقبلها وتُرفض كل محاولة. عيّن كلمة مرور باستخدام sudo passwd youruser، أو استخدم حساباً مختلفاً للوحة.

هل يدير Cockpit حاويات Docker؟

لا. تأتي صفحة الحاويات في Cockpit من cockpit-podman وتدير Podman. أُزيلت وحدة Docker القديمة منذ سنوات، ولن تعود. إذا كانت خدماتك تعمل ضمن Docker، فأدرها باستخدام ملف compose محفوظ في نظام للتحكم بالإصدارات عبر SSH، ودَع Cockpit يدير النظام المحيط بها، مثل journal والأقراص.