Ubuntu VPS साठी Cockpit की Webmin? योग्य पर्याय

Cockpit विरुद्ध Webmin: थोडक्यात उत्तर

Cockpit आणि Webmin हे दोन्ही browser मधून Linux server व्यवस्थापित करण्यासाठीचे web panels आहेत; मात्र ते वेगवेगळ्या गरजा पूर्ण करतात. Cockpit तुमच्या distribution च्या स्वतःच्या repository मध्ये उपलब्ध असतो आणि systemd, journald, polkit आणि udisks यांच्या माध्यमातून machine ची माहिती वाचतो. त्यामुळे SSH द्वारे व्यवस्थापित करत असलेला server तो तुम्हाला दाखवतो. Webmin जुना आणि कार्यक्षेत्राच्या दृष्टीने अधिक व्यापक आहे. तो Apache, BIND, Postfix, MariaDB आणि Cockpit हाताळत नसलेल्या इतर अनेक services साठी configuration files लिहितो. हे करण्यासाठी तो root म्हणून स्वतःचा web server चालवतो.

एका box चे live view, log reader आणि emergency terminal हवे असल्यास Cockpit install करा. एखादी service हाताने configure न करता form-based editor हवा असल्यास Webmin install करा. Password login सह यापैकी कोणतेही panel public port वर ठेवू नका. तुमच्याकडे आधीच दोन किंवा तीनपेक्षा अधिक servers चालू असतील, तर प्रामाणिक उत्तर अनेकदा यापैकी कोणतेही नाही असेच असते. SSH आणि Ansible चा मार्ग कोणत्याही panel पेक्षा अधिक चांगल्या प्रकारे scale होतो.

प्रत्येक panel प्रत्यक्षात काय बदलू शकतो

Cockpit चे मूलभूत install लहान असते. बहुतेक विभाग स्वतंत्र packages असतात आणि ते install न करण्याचा पर्याय तुम्ही ठेवू शकता:

• systemd services आणि timers: unit file सुरू करणे, थांबवणे, enable करणे आणि वाचणे
• journal, unit आणि priority नुसार filter केलेले; यामध्ये journalctl आणि date picker असतो
• local accounts, group membership आणि authorized SSH keys
• cockpit-storaged वापरून storage: partitions, LVM volume groups, filesystems आणि mount points
• cockpit-podman वापरून containers; हे फक्त Podman व्यवस्थापित करते
• cockpit-packagekit वापरून package updates
• cockpit-pcp वापरून CPU, memory, disk आणि network चे graphs
• browser tab मधील root terminal

Ubuntu VPS वर दोन विभाग काम करत नसल्यासारखे दिसतात, पण प्रत्यक्षात ते तसे नसते. Cockpit चे Networking page हे NetworkManager साठी front end आहे. Ubuntu server images मध्ये netplan आणि systemd-networkd वापरले जातात. त्यामुळे हे page उपलब्ध नसते किंवा रिकामे दिसते. ते परत मिळवण्यासाठी remote box वर NetworkManager install करू नका. NetworkManager interface चे नियंत्रण घेतो. तिथे झालेल्या चुकीमुळे तुमचे SSH session देखील बंद होऊ शकते. Cockpit चे firewall controls हे firewalld साठी front end आहेत. Ubuntu मध्ये ufw वापरले जाते. त्यामुळे तुम्हाला कोणतेही firewall controls मिळत नाहीत. तुम्ही terminal मध्ये sudo ufw status चालवत राहता.

Webmin मध्ये यापेक्षा बरेच अधिक भाग येतात. कारण तो एकाच program ऐवजी प्रत्येक service साठीच्या modules चा संग्रह आहे:

• forms द्वारे Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL आणि Samba configuration
• users, groups आणि disk quotas
• cron jobs आणि system clock
• package updates, तसेच upload आणि download सुविधांसह file manager
• firewall front ends, ज्यामध्ये iptables साठी एक आणि firewalld साठी एक front end आहे
• configuration file backups, तसेच एका Webmin server वरील बदल इतर Webmin servers वर लागू करणारे cluster modules

Webmin /etc अंतर्गत असलेल्या वास्तविक files मध्ये बदल करतो. Forms मागे कोणताही hidden database नसतो. त्यामुळे /etc version control मध्ये असल्यास, form save केल्यानंतर sudo git -C /etc diff module ने नेमके काय लिहिले ते दाखवते. कोणतेही Webmin page प्रत्यक्षात काय करते हे समजून घेण्याचा हा सर्वात जलद मार्ग आहे. Webmin install आणि पहिल्या login ची मार्गदर्शिका module tree चे सविस्तर स्पष्टीकरण देते. Virtualmin आणि Usermin ही त्याच engine वर तयार केलेली स्वतंत्र products आहेत. Virtualmin shared hosting साठी आणि Usermin end users साठी आहे. Exposure संदर्भात येथे सांगितलेले सर्व नियम त्यांनाही लागू होतात.

प्रत्येकाची प्रमाणीकरण पद्धत

Cockpit मध्ये स्वतंत्र user database नाही. त्याच्या login page वर /etc/pam.d/cockpit मधील PAM (pluggable authentication modules) stack चालतो. त्यामुळे accounts म्हणजे तुमचे Unix accounts आणि passwords म्हणजे तुमचे Unix passwords असतात. Root ला default स्वरूपात नकार दिला जातो, कारण /etc/cockpit/disallowed-users मध्ये त्याची नोंद आहे. Privileged actions polkit द्वारे केल्या जातात. कोणताही बदल करण्यापूर्वी interface तुमचा password पुन्हा विचारतो. त्यामुळे privilege वाढवेपर्यंत page header मध्ये "Limited access" दिसू शकते.

या रचनेचा hardened server वर एक परिणाम दिसतो. तुम्ही password authentication अक्षम करून केवळ key वापरणारे SSH login configure केले असल्यास, account कडे वापरता येण्याजोगा password नसू शकतो. त्यामुळे ssh अजूनही कार्यरत असताना Cockpit login नाकारले जाते. Server वर हे तपासा:

sudo passwd -S deploy

deploy L ने सुरू होणाऱ्या output चा अर्थ password locked आहे. त्यामुळे PAM कडे स्वीकारण्यासाठी कोणताही password नसतो आणि तुम्ही टाइप केलेला कोणताही password कार्य करणार नाही. P म्हणजे वापरता येण्याजोगा password set आहे. Cockpit चे स्वतःचे login page SSH keys स्वीकारत नाही. तुम्ही login केलेल्या machine वरून Cockpit दुसऱ्या host शी connect होताना keys फक्त त्या वेळी वापरल्या जातात.

Webmin स्वतःचे users /etc/webmin/miniserv.users मध्ये ठेवते. हे users /etc/passwd पासून स्वतंत्र असतात. Webmin ला Unix accounts विरुद्ध authenticate करण्यासाठीही configure करता येते. सर्व modules वापरण्याची परवानगी दिलेला Webmin user त्या machine वर root इतकाच privileged असतो, त्याच्या login shell मध्ये काहीही नमूद असले तरी. Webmin मध्ये स्वतःचे TOTP (time-based one-time password) support आणि repeated failed logins नंतर hosts block करण्याची स्वतःची सुविधा आहे. या दोन्ही सुविधा Webmin Configuration मध्ये enable केल्या जातात. Cockpit मध्ये second factor मिळवण्यासाठी तो PAM मध्ये add करावा लागतो, उदाहरणार्थ libpam-google-authenticator द्वारे.

प्रत्येकाची अद्ययावत प्रक्रिया

Cockpit हे तुमच्या distribution कडून packaged केले जाते. Ubuntu 24.04 मध्ये ते archive मधून येते. नवीन build साठी upstream project 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 तुम्ही install केलेली version आणि ती कोणत्या repository मधून आली हे दाखवते. backports मध्ये नवीन build उपलब्ध नसेल, तर apt archive मधील version वापरते. ते योग्य आहे. cockpit.socket चा परिणाम active (listening) असा असावा. त्यानंतर security fixes तुमच्या kernel प्रमाणेच त्याच unattended-upgrades run मधून येतात. त्यांचा publisher तुम्ही आधीपासून trust करता.

Webmin Ubuntu च्या archive मध्ये नाही. अधिकृत install आधी 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 run करण्यापूर्वी वाचा, कारण ते root म्हणून चालते. त्यानंतर server वरील प्रत्येक apt upgrade Webmin च्या repository मधूनही packages आणते. त्यामुळे या system वर root-level trust असलेला दुसरा publisher जोडला जातो. हीच Webmin ची वास्तविक किंमत आहे. ती स्पष्ट करण्यासाठी एक साधे उदाहरण पाहू: CVE-2019-15107 हे अनेक 1.9x packages मधील backdoor होते. त्यातून authentication शिवाय command execution शक्य झाले. Project चा source repository नव्हे, तर त्याचा build host compromised झाल्यामुळे ते users पर्यंत पोहोचले. Distribution packaging मुळे अशी घटना अशक्य होत नाही. मात्र, तुम्ही स्वतः maintain करत नसलेली build आणि review प्रक्रिया त्यातून मिळते.

सार्वजनिक पोर्टवर यापैकी कोणतेही ठेवू नका

Cockpit TCP 9090 वर आणि Webmin TCP 10000 वर ऐकतात. दोन्ही TLS (transport layer security) वापरतात आणि self-signed certificate देतात. त्यामुळे सर्वप्रथम browser warning दिसते. self-signed certificate तयार करणे आणि त्यावर विश्वास ठेवणे या warning मधून कोणती माहिती मिळते आणि कोणती मिळत नाही, हे स्पष्ट करते. दोन्ही पोर्ट सतत scan केले जातात. दोन्ही panel root खात्यापर्यंत प्रवेश देतात. त्यामुळे अंदाज लावलेला किंवा पुन्हा वापरलेला password सर्व्हरचा पूर्ण ताबा मिळवून देतो.

सुरक्षित पद्धत म्हणजे panel ला localhost वर bind करणे आणि SSH tunnel द्वारे त्यात प्रवेश करणे. Cockpit साठी socket unit override करा:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

स्वतंत्र ओळीवर असलेला रिकामा ListenStream= आवश्यक आहे. systemd list settings मध्ये नवीन मूल्ये append करते. त्यामुळे हा रिकामा घटक नसल्यास unit मध्ये मूळ 0.0.0.0:9090 कायम राहतो आणि नवीन address त्याला जोडला जातो. परिणामी panel अजूनही सार्वजनिक राहतो. Override लागू करा आणि कोणते address listening स्थितीत आहेत ते तपासा:

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

Output मध्ये 127.0.0.1:9090 दिसणे आवश्यक आहे. *:9090 किंवा 0.0.0.0:9090 असा address दिसल्यास override लागू झालेला नाही. आता स्वतःच्या machine वरून tunnel उघडा आणि https://localhost:9090 वर browser उघडा:

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

Local port आणि remote port समान ठेवा. Cockpit browser मधील Origin header ची तुलना तो स्वतः सेवा देत असल्याचे मानत असलेल्या address शी करतो. त्यामुळे local port 9999 वरून केलेला tunnel login page लोड करतो, पण login वेळी अपयशी ठरतो. नाकारलेला origin journalctl -u cockpit मध्ये नोंदवला जातो. वेगळा local port हवा असल्यास तो /etc/cockpit/cockpit.conf मध्ये द्या:

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

तो बदल लागू करण्यासाठी sudo systemctl restart cockpit.socket वापरून restart करा. Webmin साठी समतुल्य setting /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

Form post करताना Webmin Referer header देखील तपासतो. दुसऱ्या host कडून आल्यासारख्या दिसणाऱ्या requests तो नाकारतो. त्यामुळे reverse proxy ची पहिली configuration अपयशी ठरते. त्याच file मधील referers= line मध्ये proxy चे hostname परवानगी द्यायचे असते. webprefix= मध्ये Webmin कोणत्या path अंतर्गत उपलब्ध आहे ते सांगायचे असते.

Authenticated reverse proxy हा दुसरा पर्याय आहे: पुढे nginx आणि login साठी Authentik single sign-on layer. ही रचना कार्य करते, पण ती दुसऱ्या क्रमांकाची निवड आहे. Proxy मागे panel अजूनही root म्हणून चालतो. तसेच आता एकाऐवजी दोन प्रवेशद्वारांची देखभाल करावी लागते. Tunnel मुळे internet वर कोणतीही listening service उघडत नाही. तसेच तो तुम्ही आधीपासून सुरक्षित ठेवत असलेला SSH key पुन्हा वापरतो.

Production सेवा आधीच चालू असलेल्या सर्व्हरवर कोणते panel वापरावे?

इतर लोक त्या मशीनवर अवलंबून असतील, तेव्हा महत्त्वाच्या दोन कारणांमुळे Cockpit निवडा. ते socket activated आहे. त्यामुळे session उघडे असतानाच cockpit-ws चालते आणि port वर कायमस्वरूपी root daemon प्रतीक्षा करत राहत नाही. तसेच ते कोणत्याही सेवेची मालकी घेत नाही. Package काढून टाकल्यानंतरही प्रत्येक सेवा आधीप्रमाणेच चालू राहते, कारण Cockpit स्वतःची configuration साठवत नाही. कोणी login केलेले नसले तरी Webmin चे miniserv.pl resident राहते. तुमच्या system वर त्याचा memory खर्च किती आहे हे systemctl status webmin वापरून तपासा. यामुळे चालू process ची resident memory दिसते.

Webmin चे DNS किंवा mail modules आवश्यक असतील, तर त्यांच्यासाठी स्वतंत्र server द्या. 127.0.0.1 ला bind केलेला आणि एकच काम करणारा Webmin server हा नियंत्रित जोखीम असतो. ग्राहकांना दिसणाऱ्या application सोबत त्याच host वर Webmin चालवणे सुरक्षित नाही. दोन्हीपैकी कोणतेही panel install करण्यापूर्वी मूलभूत कामे पूर्ण करा: नवीन VPS वरील पहिली दहा मिनिटे या मार्गदर्शिकेत दोन्ही panels आधीपासून उपलब्ध असल्याचे गृहीत धरत असलेला non-root user आणि firewall यांची माहिती दिली आहे.

जेव्हा दोन्ही पर्याय योग्य ठरत नाहीत

Panel प्रत्येक server साठी स्वतंत्रपणे आणि manually वापरावे लागते. तसेच काय बदलले किंवा का बदलले याची कोणतीही नोंद त्यात राहत नाही. एका box साठी हे ठीक आहे. पाच box असतील, तर तेच काम पुन्हा पुन्हा करावे लागते. वीस box असतील, तर कोणत्या server वर बदल राहून गेला हे अंदाजाने शोधावे लागते. Cockpit SSH द्वारे एकाच session मध्ये इतर hosts जोडू शकते. मात्र अलीकडील versions मध्ये हे default ने disabled असते आणि AllowMultiHost=yes ला /etc/cockpit/cockpit.conf मध्ये आवश्यक असते. तरीही तोच बदल पाच वेळा click करून करावा लागतो.

याऐवजी तुमची configuration git repository मध्ये ठेवून plain SSH वापरा. एकाच ठिकाणाहून अनेक Linux servers व्यवस्थापित करणे या मांडणीचे स्वरूप स्पष्ट करते. पहिले Ansible playbook एका file मधून प्रत्येक host वर समान firewall rule लागू करते. तो बदल diff म्हणून review करता येतो. Container संबंधी कामही याच पद्धतीने करा: Docker Compose मूलभूत मार्गदर्शक मध्ये दाखवल्याप्रमाणे, git मधील file वरून SSH द्वारे docker compose up -d चालवणे कोणत्याही panel मध्ये click करण्यापेक्षा अधिक चांगले आहे. शिवाय Cockpit मुळात Docker व्यवस्थापित करत नाही.

Terminal ज्या कामांसाठी अडचणीची ठरते, त्यासाठी panel वापरा. उदाहरणार्थ, metrics graph वाचणे किंवा चाळीस units पैकी कोणत्या failed आहेत हे ओळखणे. जे काम दोनपेक्षा अधिक वेळा करणार असाल, त्यासाठी code वापरा.

अपयशाच्या परिस्थिती आणि दिसणारे संदेश

SSH ने स्वीकारलेला पासवर्ड Cockpit नाकारतो. खाते केवळ key-based authentication साठी आहे. sudo passwd -S alice दुसऱ्या field मध्ये L दाखवते, त्यामुळे PAM कडे तपासण्यासाठी पासवर्ड उपलब्ध नसतो. sudo passwd alice वापरून पासवर्ड सेट करा किंवा ते खाते SSH साठीच ठेवा आणि Cockpit मध्ये दुसऱ्या user ने login करा.

योग्य पासवर्ड असूनही Cockpit root नाकारतो. /etc/cockpit/disallowed-users मध्ये root नोंदलेले असते. sudo अधिकार असलेल्या सामान्य user ने login करा. ही अपेक्षित पद्धत आहे, कारण त्यानंतर polkit कोणत्या व्यक्तीने privilege escalation केली ते नोंदवते.

Cockpit मध्ये Networking किंवा Firewall page दिसत नाही. या pages साठी NetworkManager आणि firewalld आवश्यक आहेत. Ubuntu VPS मध्ये netplan, systemd-networkd आणि ufw वापरले जातात, त्यामुळे हे pages दिसत नाहीत. काहीही बिघडलेले नाही. SSH वरून ufw वापरत राहणे हाच उपाय आहे.

Tunnel द्वारे Cockpit चे login page उघडते, परंतु login अयशस्वी होते. तुमचा local port आणि remote port वेगळे आहेत. त्यामुळे Origin check अयशस्वी होतो आणि journalctl -u cockpit ते दाखवते. Ports समान करा किंवा /etc/cockpit/cockpit.conf मध्ये Origins सेट करा.

Webmin ला proxy मागे ठेवल्यानंतर form post अयशस्वी होतात. Referer check ते नाकारते. /etc/webmin/miniserv.conf मधील referers= मध्ये proxy hostname जोडा आणि panel एखाद्या path अंतर्गत उपलब्ध असल्यास webprefix= सेट करा.

Panel सार्वजनिकरीत्या उपलब्ध आहे की नाही याची खात्री नाही. सर्व्हरवरून sudo ss -lntp | grep -E '9090|10000' याचे उत्तर देते. Webmin प्रत्येक login प्रयत्न /var/webmin/miniserv.log मध्ये नोंदवते. Listening configuration मध्ये कोणताही बदल केल्यानंतर हा log एकदा वाचणे उपयुक्त ठरते.

FAQ

एकाच Ubuntu VPS साठी Cockpit किंवा Webmin यापैकी कोणते चांगले आहे?

बहुतेक वापरकर्त्यांसाठी Cockpit योग्य आहे. ते Ubuntu च्या स्वतःच्या repository मधून येते, उर्वरित system सोबत patch केले जाते आणि browser session सुरू असतानाच चालते. Cockpit ज्या सेवेला स्पर्श करत नाही, अशा BIND किंवा Postfix सारख्या सेवेसाठी form-based editor आवश्यक असल्यास Webmin निवडा. मात्र त्याच्या बदल्यात त्याचा web server नेहमी root म्हणून चालतो आणि त्याची updates Webmin च्या स्वतःच्या repository मधून येतात.

Cockpit आणि Webmin एकाच server वर चालवता येतात का?

होय. ते 9090 आणि 10000 हे वेगवेगळे ports वापरतात. प्रत्येक panel system वर थेट बदल करतो; त्यामुळे त्यांच्यात conflict होत नाही. तरीही हा योग्य trade-off नाही. एकाच machine वर प्रत्येक panel मधून root-सक्षम स्वतंत्र login मिळतो. त्यामुळे काही clicks वाचवण्यासाठी exposure दुप्पट होते. दोन्ही install केल्यास, दोन्ही 127.0.0.1 ला bind करा आणि SSH tunnel द्वारे त्यांच्यापर्यंत पोहोचा.

Port 9090 किंवा 10000 इंटरनेटवर उघडणे सुरक्षित आहे का?

Password login वापरत असल्यास नाही. दोन्ही panels root पर्यंत प्रवेश देतात. हे ports उघडल्यानंतर काही तासांत routine scanning मध्ये आढळतात. Panel ला 127.0.0.1 ला bind करा. त्यानंतर ssh -N -L 9090:127.0.0.1:9090 user@host चालवा आणि https://localhost:9090 उघडा. sudo ss -lntp | grep 9090 वापरून पडताळणी करा. त्यात 0.0.0.0:9090 ऐवजी 127.0.0.1:9090 दिसले पाहिजे. Authenticated reverse proxy हा स्वीकारार्ह दुसरा पर्याय आहे.

SSH key ने login होत असताना माझा Cockpit login का अयशस्वी होतो?

Cockpit PAM द्वारे Unix password वापरून authentication करते. त्याचे login page SSH keys स्वीकारत नाही. Hardened server वर त्या account साठी usable password नसतो. sudo passwd -S youruser चालवा. दुसऱ्या field मध्ये L असल्यास password locked आहे. त्यामुळे PAM कडे स्वीकारण्यासाठी password नसतो आणि प्रत्येक प्रयत्न नाकारला जातो. sudo passwd youruser वापरून password set करा किंवा panel साठी वेगळे account वापरा.

Cockpit Docker containers व्यवस्थापित करते का?

नाही. Cockpit चे container page cockpit-podman मधून येते आणि Podman व्यवस्थापित करते. जुना Docker module काही वर्षांपूर्वी काढून टाकण्यात आला असून तो पुन्हा येणार नाही. तुमच्या services Docker अंतर्गत चालत असल्यास, SSH द्वारे version control मधील compose file वापरून त्यांचे व्यवस्थापन करा. Cockpit कडून त्याभोवतालचे system, जसे journal आणि disks, व्यवस्थापित करून घ्या.