Ubuntu VPS کے لیے Cockpit یا Webmin؟

Cockpit بمقابلہ Webmin: مختصر جواب

Cockpit اور Webmin دونوں browser کے ذریعے Linux server manage کرنے کے لیے web panels ہیں، لیکن دونوں مختلف ضرورتیں پوری کرتے ہیں۔ Cockpit آپ کی distribution کے اپنے repository میں دستیاب ہوتا ہے اور systemd، journald، polkit اور udisks کے ذریعے machine کی معلومات پڑھتا ہے۔ اس لیے یہ ایسے server کا جائزہ دکھاتا ہے جسے آپ اب بھی SSH کے ذریعے manage کرتے ہیں۔ Webmin پرانا اور دائرۂ کار کے لحاظ سے زیادہ وسیع ہے۔ یہ Apache، BIND، Postfix، MariaDB اور درجنوں دیگر services کی configuration files لکھتا ہے، جنہیں Cockpit کبھی تبدیل نہیں کرتا۔ یہ کام کرنے کے لیے Webmin اپنا web server بطور root چلاتا ہے۔

جب آپ ایک server کی live حالت، logs پڑھنے کی سہولت اور emergency terminal چاہتے ہوں تو Cockpit install کریں۔ جب آپ کسی ایسی service کے لیے form-based editor چاہتے ہوں جسے آپ دستی طور پر configure نہیں کرنا چاہتے، تو Webmin install کریں۔ ان میں سے کسی کو بھی password login کے ساتھ public port پر نہ چلائیں۔ اگر آپ پہلے ہی دو یا تین سے زیادہ servers چلا رہے ہیں، تو اکثر درست جواب دونوں میں سے کوئی نہیں ہوتا۔ SSH اور Ansible کا طریقہ کسی بھی panel کے مقابلے میں بہتر طور پر scale ہوتا ہے۔

ہر پینل حقیقت میں کیا تبدیل کر سکتا ہے

Cockpit کی بنیادی installation چھوٹی ہوتی ہے، اور زیادہ تر حصے الگ packages پر مشتمل ہوتے ہیں جنہیں آپ شامل نہ کرنے کا انتخاب کر سکتے ہیں:

• systemd services اور timers: unit file کو start، stop، 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 manage کرتا ہے
• 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 نہ کریں، کیونکہ یہ interface کا control سنبھال لیتا ہے، اور وہاں کی گئی غلطی سے SSH session بھی ختم ہو سکتا ہے۔ Cockpit کے firewall controls، firewalld کا front end ہیں، جبکہ Ubuntu، ufw استعمال کرتا ہے؛ اس لیے آپ کو firewall controls بالکل نہیں ملتے۔ آپ terminal میں sudo ufw status چلاتے رہیں۔

Webmin کہیں زیادہ وسیع کام کرتا ہے، کیونکہ یہ ایک پروگرام کے بجائے ہر 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 کے لیے ہے
• configuration file backups، اور cluster modules جو ایک تبدیلی دوسرے Webmin servers پر بھیجتے ہیں

Webmin، /etc کے تحت موجود اصل files میں تبدیلی کرتا ہے۔ Forms کے پیچھے کوئی hidden database نہیں ہوتا، اس لیے اگر /etc version control میں ہو تو form save کرنے کے بعد sudo git -C /etc diff بالکل وہی دکھاتا ہے جو module نے لکھا ہے۔ یہ جاننے کا تیز ترین طریقہ ہے کہ Webmin کا کوئی بھی page حقیقت میں کیا کرتا ہے۔ Webmin installation اور پہلی login کا walkthrough میں module tree کی تفصیل دی گئی ہے۔ Virtualmin اور Usermin اسی engine پر بنے ہوئے الگ products ہیں؛ Virtualmin shared hosting کے لیے اور Usermin end users کے لیے ہے۔ Exposure کے بارے میں یہاں بیان کی گئی تمام باتیں ان دونوں پر بھی لاگو ہوتی ہیں۔

ہر ایک authentication کیسے کرتا ہے

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 طلب کرتا ہے۔ اسی لیے escalate کرنے تک page header میں "Limited access" دکھائی دے سکتا ہے۔

Hardened box پر اس design کا ایک نتیجہ سامنے آتا ہے۔ اگر آپ نے password authentication disabled کے ساتھ صرف key-based SSH login اختیار کیا ہے تو account کے پاس کوئی قابلِ استعمال password نہیں ہو سکتا۔ اس صورت میں Cockpit login مسترد ہو جاتا ہے، جبکہ ssh اب بھی کام کرتا ہے۔ Server پر اسے چیک کریں:

sudo passwd -S deploy

deploy L سے شروع ہونے والا output بتاتا ہے کہ password locked ہے۔ اس لیے PAM کے پاس قبول کرنے کے لیے کوئی password نہیں ہوتا، اور آپ جو بھی password درج کریں، وہ کام نہیں کرے گا۔ P کا مطلب ہے کہ قابلِ استعمال password set ہے۔ Cockpit کا اپنا login page SSH keys قبول نہیں کرتا۔ Keys صرف اس وقت استعمال ہوتی ہیں جب Cockpit اس machine سے، جس میں آپ نے login کیا ہے، کسی دوسرے host سے آگے connect کرتا ہے۔

Webmin اپنے users کو /etc/webmin/miniserv.users میں رکھتا ہے، جو /etc/passwd سے الگ ہے، اور اسے Unix accounts کے خلاف authenticate کرنے کے لیے بھی configure کیا جا سکتا ہے۔ جس Webmin user کو تمام modules کی اجازت دی گئی ہو، وہ اس machine پر root کے برابر اختیارات رکھتا ہے، خواہ اس کی login shell کچھ بھی ہو۔ Webmin اپنی TOTP (time-based one-time password) support اور repeated failed logins کے بعد hosts کو block کرنے کا اپنا mechanism فراہم کرتا ہے۔ دونوں Webmin Configuration کے اندر فعال کیے جاتے ہیں۔ Cockpit کو second factor صرف اسی صورت میں ملتا ہے جب آپ اسے PAM میں شامل کریں، مثلاً libpam-google-authenticator کے ذریعے۔

ہر ایک کو کیسے اپ ڈیٹ کیا جاتا ہے

Cockpit آپ کی distribution کے ذریعے package کیا جاتا ہے۔ 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 میں شامل نہیں ہے۔ official 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 کو چلانے سے پہلے پڑھیں، کیونکہ یہ root کے طور پر چلتی ہے۔ اس کے بعد server پر ہونے والا ہر apt upgrade Webmin کی repository سے بھی packages حاصل کرتا ہے۔ اس طرح آپ نے server پر root-level trust رکھنے والا دوسرا publisher شامل کر دیا ہے۔ Webmin کی اصل لاگت یہی ہے، اور اس کی ایک واضح مثال ضروری ہے: CVE-2019-15107 کئی 1.9x packages میں موجود ایک backdoor تھا جو authentication کے بغیر command execution کی اجازت دیتا تھا۔ یہ صارفین تک اس لیے پہنچا کہ project کا build host compromise ہو گیا تھا، نہ کہ اس کی source repository۔ Distribution packaging اس امکان کو ختم نہیں کرتی۔ البتہ اس سے build اور review کا ایک ایسا مرحلہ شامل ہو جاتا ہے جسے آپ خود maintain نہیں کر رہے ہوتے۔

عوامی port پر دونوں میں سے کوئی بھی کیوں نہیں ہونا چاہیے

Cockpit، TCP 9090 پر اور Webmin، TCP 10000 پر، دونوں TLS (transport layer security) کے ذریعے self-signed certificate کے ساتھ listen کرتے ہیں۔ اس لیے سب سے پہلے browser warning نظر آتی ہے۔ self-signed certificate بنانا اور اس پر اعتماد کرنا میں بتایا گیا ہے کہ یہ warning آپ کو کیا بتاتی ہے اور کیا نہیں بتاتی۔ دونوں ports کو مسلسل scan کیا جاتا ہے، اور دونوں panels سے root تک رسائی ملتی ہے۔ اس لیے اندازے سے لگایا گیا یا دوبارہ استعمال کیا گیا password پورے server کو breach کرنے کے لیے کافی ہے۔

محفوظ طریقہ یہ ہے کہ panel کو localhost پر bind کریں اور SSH tunnel کے ذریعے اس تک پہنچیں۔ Cockpit کے لیے socket unit کو override کریں:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

اپنی الگ line پر موجود خالی ListenStream= ضروری ہے۔ systemd list settings میں نئی قدر append کرتا ہے۔ اس کے بغیر unit اصل 0.0.0.0:9090 برقرار رکھتا ہے اور نیا address اس میں شامل کر دیتا ہے، جس سے panel اب بھی public رہتا ہے۔ override لاگو کریں اور دیکھیں کہ کون سا address listen کر رہا ہے:

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 سے کرتا ہے جس پر اسے یقین ہوتا ہے کہ وہ service دے رہا ہے۔ اس لیے local port 9999 سے بنائی گئی tunnel login page تو load کر دیتی ہے، لیکن login کے وقت ناکام ہو جاتی ہے، اور journalctl -u cockpit rejected origin کا record درج کرتا ہے۔ اگر آپ کو مختلف local port درکار ہو تو اسے /etc/cockpit/cockpit.conf میں بیان کریں:

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

اس setting کو حاصل کرنے کے لیے 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

Webmin form posts پر Referer header بھی check کرتا ہے اور ایسی requests مسترد کر دیتا ہے جو کسی دوسرے host سے آتی ہوئی معلوم ہوں۔ یہی وجہ ہے کہ reverse proxy کی پہلی کوشش ناکام ہو جاتی ہے۔ اسی file میں موجود referers= line وہ جگہ ہے جہاں proxy کا hostname allow کیا جاتا ہے، جبکہ webprefix= میں Webmin کے path کے تحت موجود ہونے کی وضاحت کی جاتی ہے۔

دوسرا اختیار authenticated reverse proxy ہے: سامنے nginx ہو اور login کے لیے Authentik single sign-on layer استعمال ہو۔ یہ کام کرتا ہے، لیکن یہ دوسرا بہتر اختیار ہے۔ Proxy کے پیچھے panel اب بھی root کے طور پر چلتا ہے، اور اب آپ ایک کے بجائے دو front doors برقرار رکھتے ہیں۔ Tunnel internet پر کوئی listening service شامل نہیں کرتی، اور یہ وہ SSH key دوبارہ استعمال کرتی ہے جس کی آپ پہلے ہی حفاظت کرتے ہیں۔

پروڈکشن سروسز چلانے والے موجودہ سرور پر کون سا panel

Cockpit، دو اہم وجوہات کی بنا پر، جو اس وقت اہم ہوتی ہیں جب دوسرے لوگ اس مشین پر انحصار کرتے ہوں۔ یہ socket activated ہے، اس لیے cockpit-ws صرف اسی وقت چلتا ہے جب کوئی session کھلا ہو، اور کسی port پر مستقل root daemon منتظر نہیں رہتا۔ یہ کسی configuration کا مالک بھی نہیں ہوتا: package ہٹانے کے بعد ہر سروس عین پہلے کی طرح چلتی رہتی ہے، کیونکہ Cockpit اپنی کوئی configuration محفوظ نہیں کرتا۔ Webmin کا miniserv.pl اس بات سے قطع نظر مسلسل چلتا رہتا ہے کہ کوئی logged in ہے یا نہیں۔ systemctl status webmin سے معلوم کریں کہ آپ کے نظام پر اس کی لاگت کتنی ہے؛ یہ چلتے ہوئے process کی resident memory دکھاتا ہے۔

اگر آپ کو Webmin کے DNS یا mail modules درکار ہوں تو ان کے لیے الگ server مختص کریں۔ ایک کام کرنے والا Webmin box، جو 127.0.0.1 پر bound ہو، محدود خطرہ رکھتا ہے۔ Webmin کا آپ کی customer-facing application کے ساتھ ایک ہی host پر چلنا محفوظ نہیں ہے۔ دونوں میں سے کوئی panel نصب کرنے سے پہلے بنیادی کام مکمل کریں: نئے VPS پر پہلے دس منٹ میں non-root user اور firewall کا طریقہ بتایا گیا ہے، جنہیں دونوں panels پہلے سے موجود فرض کرتے ہیں۔

جب کوئی بھی ایک بہتر جواب نہ ہو

Panel فی سرور الگ اور دستی ہوتا ہے، اور اس میں یہ ریکارڈ نہیں رہتا کہ کیا تبدیل کیا گیا یا کیوں کیا گیا۔ ایک server کے لیے یہ طریقہ مناسب ہے۔ پانچ servers پر آپ ایک ہی کام بار بار کرتے ہیں، اور بیس servers پر آپ اندازہ لگاتے ہیں کہ کون سا server اس تبدیلی سے رہ گیا۔ Cockpit ایک session میں SSH کے ذریعے دوسرے hosts شامل کر سکتا ہے، لیکن حالیہ versions میں یہ سہولت default طور پر disabled ہے اور AllowMultiHost=yes کو /etc/cockpit/cockpit.conf میں چاہتی ہے۔ اس کے باوجود آپ کو وہی تبدیلی پانچ مرتبہ click کر کے کرنی پڑتی ہے۔

متبادل یہ ہے کہ plain SSH استعمال کریں اور اپنی configuration کو git repository میں رکھیں۔ ایک جگہ سے متعدد Linux servers کا انتظام اس setup کی ساخت بیان کرتا ہے، جبکہ پہلا Ansible playbook ایک ہی file سے ہر host پر وہی firewall rule لاگو کرتا ہے، جسے آپ diff کی صورت میں review کر سکتے ہیں۔ Container کا کام بھی اسی طرح کیا جاتا ہے: git میں موجود file سے SSH کے ذریعے docker compose up -d چلانا، جیسا کہ Docker Compose کی بنیادی رہنما میں بتایا گیا ہے، کسی بھی panel میں click کرنے سے بہتر ہے۔ مزید یہ کہ Cockpit Docker کا انتظام سرے سے نہیں کرتا۔

Panel ان کاموں کے لیے استعمال کریں جن میں terminal کم مؤثر ہوتا ہے، مثلاً metrics graph پڑھنا یا یہ معلوم کرنا کہ چالیس units میں سے کون سا failed ہے۔ ہر اس کام کے لیے code استعمال کریں جسے آپ دو بار سے زیادہ کریں گے۔

خرابی کی صورتیں اور وہ strings جو آپ دیکھیں گے

Cockpit ایسے password کو مسترد کرتا ہے جسے SSH قبول کرتا ہے۔ account صرف key کے ذریعے login کے لیے configured ہے۔ sudo passwd -S alice دوسرے field میں L دکھاتا ہے، اس لیے PAM کے پاس جانچنے کے لیے کوئی password نہیں ہے۔ sudo passwd alice کے ذریعے password set کریں، یا اس account کو صرف SSH کے لیے رکھیں اور Cockpit میں کسی دوسرے user کے طور پر login کریں۔

درست password کے باوجود Cockpit root کو مسترد کرتا ہے۔ /etc/cockpit/disallowed-users میں root درج ہے۔ sudo rights والے عام user کے طور پر login کریں۔ یہی مطلوبہ طریقہ ہے، کیونکہ اس کے بعد polkit یہ record کرتا ہے کہ کس انسانی صارف نے privilege escalation کی۔

Cockpit میں Networking یا Firewall page نہیں دکھتا۔ ان pages کے لیے NetworkManager اور firewalld درکار ہیں۔ Ubuntu VPS میں netplan کے ساتھ systemd-networkd اور ufw چلتے ہیں، اس لیے یہ pages ظاہر نہیں ہوتے۔ کوئی خرابی نہیں ہے، اور حل یہ ہے کہ SSH کے ذریعے ufw استعمال کرتے رہیں۔

Cockpit کا login page tunnel کے ذریعے load ہوتا ہے، لیکن login ناکام ہو جاتا ہے۔ آپ کا local port remote port سے مختلف ہے، اس لیے Origin check ناکام ہو جاتا ہے اور journalctl -u cockpit اسے دکھاتا ہے۔ ports کو یکساں کریں، یا /etc/cockpit/cockpit.conf میں Origins set کریں۔

Proxy کے پیچھے رکھنے کے بعد Webmin form کے POST requests ناکام ہو جاتے ہیں۔ Referer check انہیں مسترد کرتا ہے۔ /etc/webmin/miniserv.conf میں referers= کے اندر proxy hostname شامل کریں، اور جب panel کسی path کے تحت serve ہو تو webprefix= set کریں۔

آپ کو یقین نہیں کہ کوئی panel exposed ہے یا نہیں۔ sudo ss -lntp | grep -E '9090|10000' server کے اندر سے اس کا جواب دیتا ہے، اور Webmin ہر login attempt کو /var/webmin/miniserv.log میں لکھتا ہے۔ اس لیے listening configuration میں کسی بھی تبدیلی کے بعد اسے ایک بار پڑھنا مفید ہے۔

FAQ

کیا ایک Ubuntu VPS کے لیے Cockpit یا Webmin بہتر ہے؟

زیادہ تر لوگوں کے لیے Cockpit بہتر ہے، کیونکہ یہ Ubuntu کی اپنی repository سے آتا ہے، سسٹم کے باقی حصوں کے ساتھ patch ہوتا ہے، اور صرف اس وقت چلتا ہے جب browser session کھلا ہو۔ Webmin اس وقت منتخب کریں جب آپ کو ایسی service کے لیے form-based editor درکار ہو جسے Cockpit manage نہیں کرتا، مثلاً BIND یا Postfix۔ اس کے بدلے یہ بات قبول کرنا ہوگی کہ اس کا web server ہر وقت root کے طور پر چلتا ہے اور اس کی updates Webmin کی اپنی repository سے آتی ہیں۔

کیا میں ایک ہی server پر Cockpit اور Webmin چلا سکتا ہوں؟

ہاں۔ یہ مختلف ports، 9090 اور 10000، استعمال کرتے ہیں اور ان میں تصادم نہیں ہوتا، کیونکہ ہر panel سسٹم کا مالک بننے کے بجائے اسے براہِ راست edit کرتا ہے۔ پھر بھی یہ اچھا تبادلہ نہیں ہے۔ ایک ہی machine پر ہر panel الگ root-capable login فراہم کرتا ہے، اس لیے چند clicks بچانے کے لیے exposure دوگنا ہو جاتا ہے۔ اگر دونوں install کریں تو دونوں کو 127.0.0.1 پر bind کریں اور SSH tunnel کے ذریعے ان تک رسائی حاصل کریں۔

کیا port 9090 یا 10000 کو internet کے لیے کھولنا محفوظ ہے؟

Password login کے ساتھ نہیں۔ دونوں panels root تک رسائی دیتے ہیں، اور کھولنے کے چند گھنٹوں کے اندر routine scanning میں دونوں ports مل جاتے ہیں۔ 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 دوسرا قابلِ قبول طریقہ ہے۔

جب key کے ذریعے SSH کام کرتا ہے تو میرا Cockpit login کیوں ناکام ہوتا ہے؟

Cockpit PAM کے ذریعے Unix password سے authentication کرتا ہے، اور اس کا login page SSH keys قبول نہیں کرتا۔ Hardened server پر account کے پاس اکثر قابلِ استعمال password نہیں ہوتا۔ sudo passwd -S youruser چلائیں: دوسرے field میں L کا مطلب ہے کہ password locked ہے، اس لیے PAM کے پاس قبول کرنے کے لیے کچھ نہیں ہوتا اور ہر کوشش مسترد ہو جاتی ہے۔ sudo passwd youruser کے ذریعے password set کریں، یا 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، manage کرنے دیں۔