Cockpit vs Webmin: Ubuntu VPS के लिए कौन सा बेहतर है?

Cockpit बनाम Webmin: संक्षिप्त उत्तर

Cockpit और Webmin दोनों ही ब्राउज़र के माध्यम से Linux सर्वर को प्रबंधित करने के लिए वेब पैनल हैं, और ये अलग-अलग जरूरतों को पूरा करते हैं। Cockpit आपके डिस्ट्रीब्यूशन के अपने रिपॉजिटरी में उपलब्ध होता है और यह systemd, journald, polkit और udisks के माध्यम से मशीन को पढ़ता है, इसलिए यह आपको वह सर्वर दिखाता है जिसे आप अभी भी SSH के माध्यम से प्रबंधित करते हैं। Webmin पुराना है और काफी व्यापक है: यह Apache, BIND, Postfix, MariaDB और दर्जनों अन्य सेवाओं के लिए कॉन्फ़िगरेशन फाइलें लिखता है जिन्हें Cockpit कभी नहीं छूता है, और ऐसा करने के लिए यह root के रूप में अपना स्वयं का वेब सर्वर चलाता है।

जब आप एक सर्वर का लाइव व्यू, लॉग रीडर और इमरजेंसी टर्मिनल चाहते हैं, तो Cockpit इंस्टॉल करें। जब आपको किसी ऐसी सेवा के लिए फॉर्म-आधारित एडिटर की आवश्यकता हो जिसे आप मैन्युअल रूप से कॉन्फ़िगर नहीं करना चाहते हैं, तो Webmin इंस्टॉल करें। इनमें से किसी को भी पासवर्ड लॉगिन के साथ पब्लिक पोर्ट पर न रखें। यदि आप पहले से ही दो या तीन से अधिक सर्वर चला रहे हैं, तो ईमानदार उत्तर अक्सर यह होता है कि इनमें से किसी की भी आवश्यकता नहीं है, और SSH के साथ Ansible का उपयोग करना किसी भी पैनल की तुलना में बेहतर तरीके से स्केल करता है।

प्रत्येक पैनल वास्तव में क्या बदल सकता है

Cockpit का बेस इंस्टॉलेशन छोटा है, और अधिकांश क्षेत्र अलग-अलग पैकेज हैं जिन्हें आप छोड़ सकते हैं:

• systemd services और timers: start, stop, enable करना और unit file को पढ़ना
• journal, जिसे unit और priority के आधार पर फ़िल्टर किया जा सकता है, जो journalctl के साथ एक date picker है
• local accounts, group membership, और authorized SSH keys
• cockpit-storaged के साथ storage: partitions, LVM volume groups, filesystems और mount points
• cockpit-podman के साथ containers, जो केवल Podman को manage करता है
• cockpit-packagekit के साथ package updates
• CPU, memory, disk और network के ग्राफ, cockpit-pcp के साथ
• ब्राउज़र टैब में एक root terminal

Ubuntu VPS पर दो क्षेत्र टूटे हुए दिखते हैं, लेकिन वे वास्तव में ऐसे नहीं हैं। Cockpit का Networking पेज NetworkManager के लिए एक front end है, और Ubuntu server images netplan के साथ systemd-networkd का उपयोग करते हैं, इसलिए वह पेज गायब या खाली रहता है। इसे वापस पाने के लिए remote box पर NetworkManager इंस्टॉल न करें, क्योंकि यह interface का नियंत्रण ले लेता है और वहां की गई एक गलती आपकी SSH session भी छीन सकती है। Cockpit के firewall controls firewalld के लिए एक front end हैं, और Ubuntu ufw का उपयोग करता है, इसलिए आपको कोई firewall control नहीं मिलता है। आप terminal में sudo ufw status चलाना जारी रखें।

Webmin कहीं अधिक क्षेत्रों को कवर करता है, क्योंकि यह एक प्रोग्राम के बजाय प्रति-service मॉड्यूल का संग्रह है:

• Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL और Samba कॉन्फ़िगरेशन, फॉर्म के माध्यम से
• users, groups और disk quotas
• cron jobs और system clock
• package updates, साथ ही upload और download की सुविधा वाला file manager
• firewall front ends, जिसमें iptables और firewalld के लिए एक-एक शामिल है
• कॉन्फ़िगरेशन फ़ाइल बैकअप, और cluster मॉड्यूल जो एक बदलाव को अन्य Webmin सर्वरों पर पुश करते हैं

Webmin /etc के अंतर्गत वास्तविक फ़ाइलों को संपादित करता है। फॉर्म के पीछे कोई छिपा हुआ डेटाबेस नहीं है, इसलिए यदि /etc version control में है, तो फॉर्म सेव करने के बाद sudo git -C /etc diff ठीक वही दिखाता है जो मॉड्यूल ने लिखा है। यह सीखने का सबसे तेज़ तरीका है कि कोई भी Webmin पेज वास्तव में क्या करता है। Webmin इंस्टॉलेशन और पहली बार लॉगिन का वॉकथ्रू मॉड्यूल ट्री का विस्तार से वर्णन करता है। Virtualmin और Usermin एक ही इंजन पर निर्मित अलग-अलग उत्पाद हैं, जो shared hosting और end users के लिए हैं, और वे यहाँ exposure के बारे में कही गई हर बात को विरासत में प्राप्त करते हैं।

प्रत्येक का प्रमाणीकरण कैसे होता है

Cockpit का अपना कोई user database नहीं है। इसका login page /etc/pam.d/cockpit में PAM (pluggable authentication modules) stack चलाता है, इसलिए accounts आपके Unix accounts होते हैं और passwords आपके Unix passwords होते हैं। Root को डिफ़ॉल्ट रूप से मना कर दिया जाता है क्योंकि /etc/cockpit/disallowed-users में इसे सूचीबद्ध किया गया है। विशेषाधिकार प्राप्त क्रियाएं (privileged actions) polkit के माध्यम से होती हैं, और interface किसी भी बदलाव से पहले आपसे फिर से password मांगता है। यही कारण है कि जब तक आप access escalate नहीं करते, page header पर "Limited access" लिखा हो सकता है।

इस डिज़ाइन का एक परिणाम उन लोगों को मिलता है जो hardened server का उपयोग करते हैं। यदि आपने password authentication अक्षम करके केवल key-based SSH login का पालन किया है, तो account का कोई भी उपयोग योग्य password नहीं हो सकता है। इसलिए Cockpit login अस्वीकार कर दिया जाता है जबकि ssh अभी भी काम करता है। इसे server पर जांचें:

sudo passwd -S deploy

deploy L से शुरू होने वाला output यह दर्शाता है कि password locked है, इसलिए PAM के पास स्वीकार करने के लिए कुछ नहीं है और आपके द्वारा टाइप किया गया कोई भी password काम नहीं कर सकता है। P का अर्थ है कि एक उपयोग योग्य password सेट है। Cockpit का अपना login page SSH keys स्वीकार नहीं करता है। Keys का उपयोग केवल तब किया जाता है जब Cockpit उस machine से आगे किसी अन्य host से जुड़ता है जहाँ आपने login किया है।

Webmin अपने स्वयं के users को /etc/webmin/miniserv.users में रखता है, जो /etc/passwd से अलग होते हैं, और इसे Unix accounts के विरुद्ध प्रमाणीकरण करने के लिए भी कहा जा सकता है। जिस Webmin user को सभी modules दिए गए हैं, वह उस machine पर root होता है, चाहे उनका login shell कुछ भी कहे। Webmin अपना स्वयं का TOTP (time-based one-time password) support और बार-बार failed login के बाद hosts को block करने की सुविधा प्रदान करता है, ये दोनों Webmin Configuration के अंदर चालू किए जाते हैं। Cockpit को second factor केवल तभी मिलता है जब आप PAM में एक जोड़ते हैं, उदाहरण के लिए libpam-google-authenticator के साथ।

प्रत्येक को अपडेट कैसे किया जाता है

Cockpit आपके distribution द्वारा पैकेज किया जाता है। Ubuntu 24.04 पर यह archive से आता है, और upstream project नए build के लिए 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 आपके द्वारा इंस्टॉल किए गए version और उस repository को प्रिंट करता है जहाँ से वह आया है। यदि backports में कोई नया build नहीं है, तो apt वापस archive version पर चला जाता है, जो कि ठीक है। cockpit.socket को active (listening) पढ़ना चाहिए। इसके बाद security fixes उसी unattended-upgrades run के माध्यम से आते हैं जिससे आपका kernel अपडेट होता है, और यह ऐसे publisher से आते हैं जिस पर आप पहले से भरोसा करते हैं।

Webmin, Ubuntu के archive में नहीं है। आधिकारिक इंस्टॉलेशन सबसे पहले Webmin की अपनी repository और signing key को जोड़ता है:

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

उस script को चलाने से पहले उसे पढ़ें, क्योंकि वह root के रूप में चलती है। उसके बाद से सर्वर पर हर apt upgrade, Webmin की repository से भी डेटा खींचता है, इसलिए आपने सर्वर पर root-level trust वाला एक दूसरा publisher जोड़ लिया है। Webmin की यही वास्तविक कीमत है, और यह एक स्पष्ट उदाहरण के योग्य है: CVE-2019-15107 कई 1.9x पैकेजों में एक backdoor था जिसने unauthenticated command execution की अनुमति दी थी, और यह उपयोगकर्ताओं तक इसलिए पहुँचा क्योंकि project का build host breached हो गया था, न कि उसका source repository। Distribution packaging इसे असंभव नहीं बनाती है। यह केवल एक build और review चरण जोड़ती है जिसे आप स्वयं maintain नहीं कर रहे हैं।

सार्वजनिक पोर्ट पर दोनों में से किसी को भी क्यों नहीं रखना चाहिए

Cockpit TCP 9090 पर और Webmin TCP 10000 पर listen करता है। दोनों TLS (transport layer security) का उपयोग करते हैं और self-signed certificate के साथ आते हैं, इसलिए सबसे पहले आपको ब्राउज़र चेतावनी दिखाई देती है। Creating and trusting a self-signed certificate यह बताता है कि वह चेतावनी क्या बताती है और क्या नहीं। दोनों पोर्ट्स को लगातार स्कैन किया जाता है और दोनों पैनल root एक्सेस देते हैं, इसलिए यदि पासवर्ड का अनुमान लगा लिया जाए या उसे दोबारा इस्तेमाल किया जाए, तो सर्वर पूरी तरह से breach हो सकता है।

सुरक्षित तरीका यह है कि पैनल को localhost पर bind करें और SSH tunnel के माध्यम से उस तक पहुँचें। Cockpit के लिए, socket unit को override करें:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

खाली ListenStream= का अपनी लाइन पर होना आवश्यक है। systemd लिस्ट सेटिंग्स में append करता है, इसलिए इसके बिना unit मूल 0.0.0.0:9090 को बनाए रखेगा और नया पता जोड़ देगा, जिससे आपका पैनल सार्वजनिक ही रहेगा। Override लागू करें और जाँचें कि क्या listen हो रहा है:

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 का पता होने का मतलब है कि override प्रभावी नहीं हुआ। अब अपनी मशीन से tunnel खोलें और https://localhost:9090 पर ब्राउज़ करें:

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

स्थानीय पोर्ट को remote पोर्ट के समान रखें। Cockpit ब्राउज़र के Origin हेडर की तुलना उस पते से करता है जिसे वह serve कर रहा है, इसलिए स्थानीय पोर्ट 9999 से tunnel लॉगिन पेज तो लोड कर देगा लेकिन लॉगिन पर विफल हो जाएगा, और journalctl -u cockpit अस्वीकृत origin को रिकॉर्ड करेगा। यदि आपको किसी अलग स्थानीय पोर्ट की आवश्यकता है, तो उसे /etc/cockpit/cockpit.conf में निर्दिष्ट करें:

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

इसे लागू करने के लिए sudo systemctl restart cockpit.socket के साथ restart करें। 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 के hostname को अनुमति देते हैं, और webprefix= वह जगह है जहाँ आप Webmin को बताते हैं कि यह एक path के अंतर्गत स्थित है।

एक authenticated reverse proxy दूसरा विकल्प है: सामने nginx, और लॉगिन करने के लिए Authentik single sign-on layer। यह काम करता है, और यह दूसरा सबसे अच्छा विकल्प है। पैनल अभी भी proxy के पीछे root के रूप में चलता है, और अब आप एक के बजाय दो front doors का रखरखाव करते हैं। एक tunnel इंटरनेट पर कोई listening service नहीं जोड़ती है, और यह उस SSH key का पुन: उपयोग करती है जिसे आप पहले से ही सुरक्षित रखते हैं।

ऐसे सर्वर पर कौन सा पैनल चुनें जो पहले से ही production services चला रहा है

Cockpit चुनें, इसके दो कारण हैं जो तब महत्वपूर्ण होते हैं जब अन्य लोग उस मशीन पर निर्भर हों। यह socket activated है, इसलिए cockpit-ws केवल तभी चलता है जब कोई session खुला हो और कोई स्थायी root daemon किसी port पर प्रतीक्षा नहीं कर रहा होता। और यह किसी भी चीज़ का स्वामित्व नहीं लेता: package को remove करने पर भी हर service बिल्कुल पहले की तरह चलती रहती है, क्योंकि Cockpit अपनी कोई configuration store नहीं करता। Webmin का miniserv.pl हमेशा resident रहता है, चाहे कोई logged in हो या न हो। systemctl status webmin के साथ देखें कि आपका पैनल कितनी memory ले रहा है, यह running process की resident memory को print करता है।

यदि आपको Webmin के DNS या mail modules की आवश्यकता है, तो उन्हें एक अलग सर्वर दें। एक Webmin box जो केवल एक काम करता है और 127.0.0.1 पर bound है, एक सीमित जोखिम है। Webmin का आपके customer-facing application के साथ एक ही host साझा करना जोखिम भरा है। किसी भी पैनल को install करने से पहले बुनियादी काम पूरा करें: नए VPS पर शुरुआती दस मिनट में उस non-root user और firewall को कवर किया गया है, जिनके बारे में दोनों पैनल यह मानकर चलते हैं कि वे पहले से मौजूद हैं।

जब उत्तर इनमें से कोई न हो

Panel प्रति-सर्वर और मैन्युअल होता है, और यह इस बात का कोई रिकॉर्ड नहीं छोड़ता कि क्या बदला गया या क्यों। एक सर्वर के लिए यह ठीक है। पाँच सर्वर होने पर आप खुद को दोहरा रहे होते हैं, और बीस सर्वर होने पर आप यह अनुमान लगा रहे होते हैं कि किस सर्वर पर बदलाव छूट गया। Cockpit एक सत्र में SSH के माध्यम से अन्य hosts को जोड़ सकता है, लेकिन हाल के संस्करणों में यह डिफ़ॉल्ट रूप से अक्षम है और AllowMultiHost=yes की मांग /etc/cockpit/cockpit.conf में करता है, और फिर भी आपको वही बदलाव पाँच बार क्लिक करना पड़ता है।

इसका विकल्प git रिपॉजिटरी में अपने कॉन्फ़िगरेशन के साथ साधारण SSH है। एक ही स्थान से कई Linux सर्वर प्रबंधित करना उस सेटअप के स्वरूप को कवर करता है, और पहला Ansible playbook एक ही फ़ाइल से हर host पर वही firewall नियम लागू करता है जिसे आप diff के रूप में देख सकते हैं। Container का काम भी इसी तरह होता है: git में मौजूद फ़ाइल से SSH पर docker compose up -d, जैसा कि Docker Compose मूल बातें गाइड में है, किसी भी पैनल में क्लिक करने से बेहतर है, और Cockpit वैसे भी Docker को प्रबंधित नहीं करता है।

पैनल का उपयोग उन कार्यों के लिए करें जिनमें टर्मिनल अच्छा नहीं है, जैसे metrics ग्राफ़ पढ़ना या यह पता लगाना कि चालीस units में से कौन सी विफल रही। कोड का उपयोग किसी भी ऐसी चीज़ के लिए करें जिसे आप दो बार से अधिक करेंगे।

विफलता के प्रकार और आपको दिखाई देने वाले संदेश

Cockpit पासवर्ड अस्वीकार करता है जिसे SSH स्वीकार कर लेता है। खाता केवल-की (key-only) है। sudo passwd -S alice दूसरे फ़ील्ड में L प्रिंट करता है, इसलिए PAM के पास जाँचने के लिए कोई पासवर्ड नहीं है। sudo passwd alice के साथ एक पासवर्ड सेट करें, या उस खाते को केवल SSH के लिए रखें और किसी अन्य उपयोगकर्ता के रूप में Cockpit में लॉग इन करें।

सही पासवर्ड होने पर भी Cockpit root को अस्वीकार कर देता है। /etc/cockpit/disallowed-users में root सूचीबद्ध है। sudo अधिकारों वाले एक सामान्य उपयोगकर्ता के रूप में लॉग इन करें। यही वांछित तरीका है, क्योंकि polkit तब रिकॉर्ड करता है कि किस व्यक्ति ने विशेषाधिकार बढ़ाए (escalate किए)।

Cockpit में Networking या Firewall पेज नहीं दिख रहे हैं। उन पेजों के लिए NetworkManager और firewalld की आवश्यकता होती है। एक Ubuntu VPS, systemd-networkd और ufw के साथ netplan चलाता है, इसलिए वे पेज दिखाई नहीं देते। कुछ भी टूटा नहीं है, और इसका समाधान SSH पर ufw का उपयोग जारी रखना है।

Cockpit लॉगिन पेज टनल के माध्यम से लोड होता है, फिर लॉगिन विफल हो जाता है। आपका स्थानीय पोर्ट रिमोट पोर्ट से अलग है, इसलिए Origin जाँच विफल हो जाती है और journalctl -u cockpit इसे दिखाता है। पोर्ट का मिलान करें, या /etc/cockpit/cockpit.conf में Origins सेट करें।

प्रॉक्सी के पीछे रखने के बाद Webmin फ़ॉर्म पोस्ट विफल हो जाते हैं। Referer जाँच उन्हें अस्वीकार कर देती है। /etc/webmin/miniserv.conf में referers= में प्रॉक्सी होस्टनेम जोड़ें, और जब पैनल को किसी पाथ के तहत सर्व किया जाता है तो webprefix= सेट करें।

आप सुनिश्चित नहीं हैं कि कोई पैनल एक्सपोज़्ड है या नहीं। sudo ss -lntp | grep -E '9090|10000' सर्वर से ही इसका उत्तर देता है, और Webmin प्रत्येक लॉगिन प्रयास को /var/webmin/miniserv.log में लिखता है, जिसे यह सुनने के तरीके में किसी भी बदलाव के बाद एक बार पढ़ना उचित है।

FAQ

क्या एक सिंगल Ubuntu VPS के लिए Cockpit बेहतर है या Webmin?

ज्यादातर लोगों के लिए Cockpit बेहतर है, क्योंकि यह Ubuntu के अपने repository से आता है, सिस्टम के बाकी हिस्सों के साथ ही patch होता है, और केवल तभी चलता है जब browser session खुला हो। Webmin तब चुनें जब आपको किसी ऐसी service के लिए form-based editor की आवश्यकता हो जिसे Cockpit support नहीं करता, जैसे कि BIND या Postfix। इसके बदले में आपको यह स्वीकार करना होगा कि इसका web server हर समय root के रूप में चलता है और इसके updates Webmin के अपने repository से आते हैं।

क्या मैं एक ही सर्वर पर Cockpit और Webmin चला सकता हूँ?

हाँ। वे अलग-अलग ports, 9090 और 10000 का उपयोग करते हैं, और उनमें कोई conflict नहीं होता, क्योंकि प्रत्येक सिस्टम को सीधे edit करता है, न कि उस पर मालिकाना हक रखता है। फिर भी यह एक अच्छा सौदा नहीं है। प्रत्येक panel एक ही मशीन पर root-capable login है, इसलिए कुछ clicks बचाने के लिए आप अपने जोखिम को दोगुना कर लेते हैं। यदि आप दोनों install करते हैं, तो दोनों को 127.0.0.1 पर bind करें और उन तक SSH tunnel के माध्यम से पहुँचें।

क्या इंटरनेट के लिए port 9090 या 10000 खोलना सुरक्षित है?

password login के साथ नहीं। दोनों panels root access देते हैं, और port खुलने के कुछ ही घंटों के भीतर routine scanning में मिल जाते हैं। Panel को 127.0.0.1 पर bind करें, फिर ssh -N -L 9090:127.0.0.1:9090 user@host चलाएँ और https://localhost:9090 पर browse करें। sudo ss -lntp | grep 9090 के साथ पुष्टि करें, जिसमें 0.0.0.0:9090 के बजाय 127.0.0.1:9090 दिखना चाहिए। एक authenticated reverse proxy दूसरा स्वीकार्य विकल्प है।

SSH key के काम करने के बावजूद मेरा Cockpit login क्यों विफल हो जाता है?

Cockpit, PAM के माध्यम से Unix password का उपयोग करके authenticate करता है, और इसका login page SSH keys स्वीकार नहीं करता है। एक hardened सर्वर पर अक्सर account का कोई usable password नहीं होता है। sudo passwd -S youruser चलाएँ: दूसरे field में L का मतलब है कि password locked है, इसलिए PAM के पास स्वीकार करने के लिए कुछ नहीं है और हर प्रयास अस्वीकार कर दिया जाता है। sudo passwd youruser के साथ password सेट करें, या panel के लिए किसी अन्य account का उपयोग करें।

क्या Cockpit Docker containers को manage करता है?

नहीं। Cockpit का container page cockpit-podman से आता है और Podman को manage करता है। पुराना Docker module वर्षों पहले हटा दिया गया था और वापस नहीं आएगा। यदि आपकी services Docker के अंतर्गत चलती हैं, तो उन्हें SSH पर version control में compose file के साथ manage करें, और Cockpit को उनके आसपास के सिस्टम, जैसे कि journal और disks को संभालने दें।