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 في علامة تبويب المتصفح

يبدو قسمان معطّلين على خادم Ubuntu VPS، لكنهما ليسا كذلك. صفحة 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 بعد حفظ النموذج يوضح ما كتبته الوحدة هناك. لكنه لا يعرض الإجراءات التي تشغّل أمراً أو تنفّذ SQL، كما تفعل وحدتا MariaDB وPostgreSQL، ولا عمليات الكتابة إلى ملفات خارج /etc. وضمن هذه الحدود، فهو أسرع طريقة لمعرفة ما تفعله صفحة 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 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 الأصل الذي يتوقعه من ترويسة Host التي يرسلها المتصفح، لذلك يمر نفق مفتوح من المنفذ المحلي 9999 إلى https://localhost:9999 بالفحص نفسه، لأن تروصيتي المتصفح Host وOrigin تحددان العنوان نفسه. يفشل الفحص عندما يغيّر شيء بين المتصفح وCockpit قيمة Host، مثل reverse proxy لا يمرر الترويسة الأصلية. عندها تُحمّل صفحة تسجيل الدخول، لكن يفشل تسجيل الدخول، ويسجل cockpit-ws القيمة received request from bad Origin. يوجد هذا السطر في journal الخاص بوحدات cockpit-wsinstance-https@، وليس cockpit.service، لذلك اقرأه باستخدام sudo journalctl -u 'cockpit-wsinstance-https@*'. لقبول عنوان عام يختلف عن العنوان الذي يراه Cockpit، حدده في /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://panel.example.com

أعد التشغيل باستخدام sudo systemctl restart cockpit لتطبيق هذا الإعداد. بالنسبة إلى 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= في /etc/webmin/config الموضع الذي تسمح فيه باسم مضيف الـ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، لكن أداة تبديل المضيفين هذه مهملة منذ Cockpit 322، وأصبح إعدادها الافتراضي يعتمد على التوزيعة، وعندما تكون معطّلة تحتاج إلى 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 خلف proxy، ثم يفشل تسجيل الدخول. غيّر proxy ترويسة Host، لذلك يفشل التحقق من Origin ويعرض sudo journalctl -u 'cockpit-wsinstance-https@*' القيمة received request from bad Origin. مرّر قيمة Host الأصلية، أو عيّن Origins في /etc/cockpit/cockpit.conf. لا يسبب نفق SSH عادي هذه المشكلة، أيّاً كان المنفذ المحلي الذي تختاره.

تفشل عمليات إرسال نماذج Webmin بعد وضعه خلف proxy. يرفضها التحقق من Referer. أضف اسم مضيف proxy إلى referers= في /etc/webmin/config، وعيّن 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 محفوظ في version control عبر SSH، ودع Cockpit يتولى إدارة النظام المحيط بها، مثل journal والأقراص.