Cockpit vs Webmin: Alin ang Mas Bagay sa Ubuntu VPS?

Cockpit kumpara sa Webmin: ang maikling sagot

Parehong web panel ang Cockpit at Webmin para sa pamamahala ng Linux server gamit ang browser, pero magkaiba ang problemang nilulutas ng mga ito. Kasama ang Cockpit sa sariling repository ng iyong distribution at binabasa nito ang machine sa pamamagitan ng systemd, journald, polkit, at udisks, kaya ipinapakita nito ang server na patuloy mo pa ring pinamamahalaan gamit ang SSH. Mas luma at mas malawak ang Webmin: nagsusulat ito sa mga configuration file para sa Apache, BIND, Postfix, MariaDB, at dose-dosenang iba pang serbisyo na hindi ina-access ng Cockpit, at nagpapatakbo ito ng sarili nitong web server bilang root para magawa iyon.

I-install ang Cockpit kung kailangan mo ng live na view ng isang server, log reader, at emergency terminal. I-install ang Webmin kung kailangan mo ng form-based editor para sa serbisyong ayaw mong i-configure nang mano-mano. Huwag ilagay ang alinman sa mga ito sa public port na gumagamit ng password login. Kung nagpapatakbo ka na ng mahigit dalawa o tatlong server, kadalasan ay neither ang tamang sagot; mas mahusay mag-scale ang SSH kasama ng Ansible kaysa sa anumang panel.

Ano ang aktuwal na nababago ng bawat panel

Maliit ang base install ng Cockpit, at magkakahiwalay na package ang karamihan sa mga bahagi nito na maaari mong hindi isama:

• mga serbisyo at timer ng systemd: simulan, ihinto, i-enable, at basahin ang unit file
• ang journal na maaaring i-filter ayon sa unit at priority, na journalctl na may date picker
• mga lokal na account, group membership, at authorized SSH keys
• storage gamit ang cockpit-storaged: partitions, LVM volume groups, filesystems, at mount points
• mga container gamit ang cockpit-podman, na Podman lamang ang mina-manage
• package updates gamit ang cockpit-packagekit
• mga graph ng CPU, memory, disk, at network gamit ang cockpit-pcp
• root terminal sa browser tab

Mukhang sira ang 2 bahagi sa isang Ubuntu VPS, pero hindi talaga. Front end ng NetworkManager ang Networking page ng Cockpit, samantalang netplan na may systemd-networkd ang ginagamit ng Ubuntu server images, kaya nawawala o walang laman ang page. Huwag mag-install ng NetworkManager sa remote box para maibalik ito, dahil kukunin nito ang pamamahala sa interface at maaaring mawalan ka rin ng SSH session kapag nagkamali ang configuration. Front end ng firewalld ang firewall controls ng Cockpit, samantalang ufw ang ginagamit ng Ubuntu, kaya wala kang makikitang firewall controls. Patuloy mong ginagamit ang sudo ufw status sa terminal.

Mas malawak ang saklaw ng Webmin dahil koleksiyon ito ng mga module para sa bawat serbisyo, hindi isang programa lamang:

• configuration ng Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL, at Samba gamit ang mga form
• mga user, group, at disk quota
• mga cron job at system clock
• package updates, kasama ang file manager na may upload at download
• mga front end para sa firewall, kabilang ang isa para sa iptables at isa para sa firewalld
• mga backup ng configuration file, at mga cluster module na nagtutulak ng isang pagbabago sa iba pang Webmin server

Inie-edit ng Webmin ang aktuwal na mga file sa ilalim ng /etc. Walang nakatagong database sa likod ng mga form, kaya kung nasa version control ang /etc, ipinapakita ng sudo git -C /etc diff pagkatapos mag-save ng form kung ano mismo ang isinulat ng module. Ito ang pinakamabilis na paraan upang malaman kung ano talaga ang ginagawa ng anumang Webmin page. Detalyadong ipinapaliwanag ng Gabay sa pag-install at unang pag-login sa Webmin ang module tree. Magkakahiwalay na product ang Virtualmin at Usermin na binuo sa parehong engine, para sa shared hosting at mga end user; pareho nilang minamana ang lahat ng nabanggit dito tungkol sa exposure.

Paano nag-a-authenticate ang bawat isa

Walang sariling user database ang Cockpit. Pinapatakbo ng login page nito ang PAM (pluggable authentication modules) stack sa /etc/pam.d/cockpit, kaya Unix accounts ang mga account at Unix passwords ang mga password. Bilang default, tinatanggihan ang root dahil nakalista ito sa /etc/cockpit/disallowed-users. Dumadaan sa polkit ang mga privileged action, at hinihingi ulit ng interface ang iyong password bago ito magbago ng anuman. Dahil dito, maaaring mabasa ang page header na "Limited access" hanggang mag-escalate ka ng privilege.

May isang epekto ang disenyong ito na karaniwang nararanasan sa hardened na server. Kung sinunod mo ang key-only SSH login na naka-disable ang password authentication, maaaring walang usable password ang account. Dahil dito, tatanggihan ang Cockpit login habang gumagana pa rin ang ssh. Suriin ito sa server:

sudo passwd -S deploy

Ang output na nagsisimula sa deploy L ay nangangahulugang naka-lock ang password. Walang matatanggap ang PAM na password, kaya hindi gagana ang anumang password na ita-type mo. Ang P ay nangangahulugang may naka-set na usable password. Hindi tumatanggap ang sariling login page ng Cockpit ng SSH keys. Ginagamit lamang ang keys kapag kumokonekta ang Cockpit mula sa machine na nilog-inan mo papunta sa isa pang host.

May sarili nitong mga user ang Webmin sa /etc/webmin/miniserv.users, hiwalay sa /etc/passwd, at maaari rin itong i-configure upang mag-authenticate laban sa Unix accounts. Ang Webmin user na binigyan ng access sa lahat ng module ay may root-level na access sa machine na iyon, anuman ang nakasaad sa login shell nito. May sariling TOTP (time-based one-time password) support ang Webmin at sarili rin nitong pag-block sa mga host matapos ang magkakasunod na failed login. Pareho itong ine-enable sa loob ng Webmin Configuration. Magkakaroon lamang ng second factor ang Cockpit kung magdadagdag ka nito sa PAM, halimbawa gamit ang libpam-google-authenticator.

Paano ina-update ang bawat isa

Naka-package ang Cockpit ng iyong distribution. Sa Ubuntu 24.04, mula ito sa archive, at inirerekomenda ng upstream project ang backports pocket para sa mas bagong build:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

Ipinapakita ng apt policy ang bersyong na-install mo at ang repository na pinagmulan nito. Kung walang mas bagong build sa backports, babalik ang apt sa bersyon mula sa archive, at ayos lang iyon. Dapat ay active (listening) ang mabasa sa cockpit.socket. Pagkatapos, darating ang mga security fix sa parehong unattended-upgrades run ng iyong kernel, mula sa publisher na pinagkakatiwalaan mo na.

Wala ang Webmin sa Ubuntu archive. Idinaragdag muna ng official install ang sariling repository at signing key ng 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

Basahin muna ang script na iyon bago ito patakbuhin dahil tumatakbo ito bilang root. Mula noon, kumukuha rin ang bawat apt upgrade sa server mula sa repository ng Webmin. Dahil dito, nagdagdag ka ng ikalawang publisher na may root-level trust sa server. Iyan ang tunay na kapalit ng paggamit ng Webmin, at dapat itong ilarawan sa isang malinaw na halimbawa: ang CVE-2019-15107 ay isang backdoor sa ilang 1.9x package na nagbigay ng command execution nang walang authentication. Nakarating ito sa mga user dahil na-breach ang build host ng project, hindi ang source repository nito. Hindi ginagawang imposible ng distribution packaging ang ganitong insidente. Nagdaragdag ito ng build at review step na hindi mo kailangang panatilihin nang ikaw mismo.

Bakit hindi dapat nasa public port ang alinman sa dalawa

Nakikinig ang Cockpit sa TCP 9090 at ang Webmin sa TCP 10000. Pareho silang gumagamit ng TLS (transport layer security) na may self-signed certificate, kaya browser warning ang unang makikita mo. Ipinapaliwanag ng Paglikha at pagtitiwala sa self-signed certificate kung ano ang sinasabi at hindi sinasabi ng warning na iyon. Patuloy na sine-scan ang dalawang port, at parehong nagbibigay ng access ang dalawang panel sa root. Kaya ang nahulaan o reused na password ay nangangahulugang ganap nang na-breach ang server.

Ang ligtas na pattern ay i-bind ang panel sa localhost at i-access ito sa pamamagitan ng SSH tunnel. Para sa Cockpit, i-override ang socket unit:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

Kinakailangan ang blangkong ListenStream= sa sarili nitong linya. Nag-a-append ang systemd sa mga list setting. Kung wala ito, mananatili ang orihinal na 0.0.0.0:9090 sa unit at idaragdag lamang ang bagong address, kaya public pa rin ang panel. Ilapat ang override at tingnan kung ano ang nakikinig:

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

Dapat ipakita ng output ang 127.0.0.1:9090. Ang address na *:9090 o 0.0.0.0:9090 ay nangangahulugang hindi nailapat ang override. Ngayon, buksan ang tunnel mula sa sarili mong machine at mag-browse sa https://localhost:9090:

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

Panatilihing kapareho ng remote port ang local port. Inihahambing ng Cockpit ang Origin header ng browser sa address na sa tingin nito ay pinagsisilbihan nito. Kaya kung local port 9999 ang gamit ng tunnel, maglo-load ang login page ngunit mabibigo sa oras ng login, at itatala sa journalctl -u cockpit ang tinanggihang origin. Kung kailangan mo ng ibang local port, ilagay ito sa /etc/cockpit/cockpit.conf:

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

Mag-restart gamit ang sudo systemctl restart cockpit.socket upang mailapat ang setting na iyon. Para sa Webmin, nasa /etc/webmin/miniserv.conf ang katumbas na setting:

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

Sinusuri rin ng Webmin ang Referer header sa mga form post at tinatanggihan ang mga request na mukhang nagmula sa ibang host. Ito ang dahilan kung bakit nabibigo ang unang pagtatangka sa paggamit ng reverse proxy. Sa parehong file, ang linyang referers= ang ginagamit para payagan ang hostname ng proxy, at ang webprefix= ang ginagamit para sabihin sa Webmin na nasa ilalim ito ng isang path.

Ang isa pang opsyon ay isang authenticated reverse proxy: nginx sa harap, na may Authentik single sign-on layer para sa login. Gumagana ito, ngunit pangalawang pinakamainam na opsyon ito. Root pa rin ang tumatakbo sa panel sa likod ng proxy, at kailangan mo nang mag-maintain ng dalawang front door sa halip na isa. Walang idinadagdag na listening service sa internet ang tunnel, at ginagamit nito muli ang SSH key na pinoprotektahan mo na.

Aling panel ang dapat gamitin sa isang server na nagpapatakbo na ng production services

Cockpit, sa dalawang kadahilanang mahalaga kapag may ibang umaasa sa machine. Socket activated ito, kaya tumatakbo lang ang cockpit-ws habang may bukas na session at walang permanenteng root daemon na naghihintay sa isang port. Wala rin itong inaangkin na configuration: kapag inalis ang package, patuloy na tatakbo ang bawat service gaya ng dati dahil walang sariling configuration na sine-save ang Cockpit. Nananatiling resident ang miniserv.pl ng Webmin kahit walang naka-log in. Tingnan kung gaano karami ang memory na ginagamit nito gamit ang systemctl status webmin, na nagpi-print ng resident memory ng tumatakbong process.

Kung kailangan mo ang DNS o mail modules ng Webmin, bigyan ito ng sariling server. Ang Webmin box na iisa lang ang trabaho at naka-bind sa 127.0.0.1 ay isang risk na madaling i-contain. Hindi ganoon ang Webmin na nakikibahagi ng host sa customer-facing application mo. Gawin muna ang base setup bago i-install ang alinmang panel: saklaw ng unang sampung minuto sa bagong VPS ang non-root user at firewall na ipinapalagay ng parehong panel na mayroon na.

Kapag hindi sapat ang alinman sa dalawa

Ang panel ay para sa bawat server at mano-mano ang paggamit, at wala itong naiiwang record kung ano ang binago o bakit. Ayos ito para sa isang box. Kapag lima na ang box, inuulit mo ang parehong gawain, at kapag dalawampu na, hinuhulaan mo kung aling server ang hindi nakatanggap ng pagbabago. Maaaring magdagdag ang Cockpit ng iba pang host sa isang session gamit ang SSH, pero naka-disable ito bilang default sa mga bagong bersyon at nangangailangan ng AllowMultiHost=yes sa /etc/cockpit/cockpit.conf. Gayunman, mauuwi ka pa rin sa pag-click sa parehong pagbabago nang limang beses.

Ang alternatibo ay plain SSH, na ang configuration mo ay nasa isang git repository. Saklaw ng Pamamahala ng ilang Linux server mula sa isang lugar ang istruktura ng setup na ito, at inilalapat ng unang Ansible playbook ang parehong firewall rule sa bawat host mula sa isang file na maaari mong suriin bilang diff. Ganito rin ang container work: mas mahusay ang docker compose up -d sa pamamagitan ng SSH mula sa isang file sa git, gaya ng nasa basic guide sa Docker Compose, kaysa sa pag-click sa anumang panel. Hindi rin talaga pinamamahalaan ng Cockpit ang Docker.

Gamitin ang panel para sa mga gawaing hindi mahusay gawin sa terminal, gaya ng pagbasa ng metrics graph o pagtukoy kung alin sa apatnapung unit ang failed. Gumamit ng code para sa anumang gawaing gagawin mo nang mahigit dalawang beses.

Mga failure mode at mga string na makikita mo

Tinatanggihan ng Cockpit ang password na tinatanggap ng SSH. Key-only ang account. Ipinapakita ng sudo passwd -S alice ang L sa second field, kaya walang password na mabe-verify ang PAM. Magtakda ng password gamit ang sudo passwd alice, o panatilihin ang account na iyon para sa SSH at mag-log in sa Cockpit gamit ang ibang user.

Tinatanggihan ng Cockpit ang root kahit tama ang password. Inililista ng /etc/cockpit/disallowed-users ang root. Mag-log in gamit ang regular na user na may sudo rights. Ito ang tamang paraan dahil itinatala ng polkit kung sinong tao ang nag-escalate ng privilege.

Walang Networking o Firewall page ang Cockpit. Kailangan ng mga page na iyon ang NetworkManager at firewalld. Ang Ubuntu VPS ay gumagamit ng netplan kasama ang systemd-networkd at ufw, kaya hindi lumilitaw ang mga page. Walang nasira, at ang dapat gawin ay ipagpatuloy ang paggamit ng ufw sa SSH.

Naglo-load ang Cockpit login page sa tunnel, pero nabibigo ang login. Magkaiba ang local port at remote port, kaya nabibigo ang check na Origin at ipinapakita ito ng journalctl -u cockpit. Itugma ang mga port, o itakda ang Origins sa /etc/cockpit/cockpit.conf.

Nabibigo ang Webmin form posts matapos itong ilagay sa likod ng proxy. Tinatanggihan ang mga ito ng check na Referer. Idagdag ang hostname ng proxy sa referers= sa /etc/webmin/miniserv.conf, at itakda ang webprefix= kapag sine-serve ang panel sa ilalim ng isang path.

Hindi ka sigurado kung exposed ang isang panel. Sinasagot ito ng sudo ss -lntp | grep -E '9090|10000' mula mismo sa server, at itinatala ng Webmin ang bawat login attempt sa /var/webmin/miniserv.log. Mainam itong basahin isang beses matapos ang anumang pagbabago sa paraan ng pakikinig nito.

FAQ

Mas mabuti ba ang Cockpit o Webmin para sa isang Ubuntu VPS?

Para sa karamihan, Cockpit, dahil galing ito sa sariling repository ng Ubuntu, kasama itong napapa-patch sa buong system, at tumatakbo lamang habang may bukas na browser session. Piliin ang Webmin kapag kailangan mo ng form-based editor para sa serbisyong hindi mina-manage ng Cockpit, gaya ng BIND o Postfix. Tanggapin kapalit nito na palaging tumatakbo bilang root ang web server nito at mula sa sariling repository ng Webmin ang mga update nito.

Maaari ko bang patakbuhin ang Cockpit at Webmin sa iisang server?

Oo. Magkaiba ang ginagamit nilang port, 9090 at 10000, at hindi sila nagkakaroon ng conflict dahil direktang ine-edit ng bawat isa ang system sa halip na ito ang pamahalaan. Hindi pa rin ito magandang trade-off. Hiwalay na root-capable login ang bawat panel sa parehong machine, kaya nadodoble ang exposure para lamang makatipid ng ilang click. Kung parehong i-install, i-bind ang dalawa sa 127.0.0.1 at i-access ang mga ito sa pamamagitan ng SSH tunnel.

Ligtas bang buksan sa internet ang port 9090 o 10000?

Hindi kung password login ang gagamitin. Parehong nagbibigay ng access sa root ang dalawang panel, at natutuklasan ang dalawang port sa routine scanning ilang oras lamang matapos buksan. I-bind ang panel sa 127.0.0.1, pagkatapos ay patakbuhin ang ssh -N -L 9090:127.0.0.1:9090 user@host at mag-browse sa https://localhost:9090. Kumpirmahin gamit ang sudo ss -lntp | grep 9090, na dapat magpakita ng 127.0.0.1:9090 sa halip na 0.0.0.0:9090. Katanggap-tanggap na second option ang authenticated reverse proxy.

Bakit nabibigo ang Cockpit login ko kahit gumagana ang SSH gamit ang key?

Nag-a-authenticate ang Cockpit sa pamamagitan ng PAM gamit ang Unix password, at hindi tumatanggap ng SSH keys ang login page nito. Sa isang hardened server, kadalasang walang usable password ang account. Patakbuhin ang sudo passwd -S youruser: ang L sa second field ay nangangahulugang naka-lock ang password, kaya walang matatanggap ang PAM at rejected ang bawat pagtatangka. Mag-set ng password gamit ang sudo passwd youruser, o gumamit ng ibang account para sa panel.

Mina-manage ba ng Cockpit ang Docker containers?

Hindi. Galing sa cockpit-podman ang container page ng Cockpit at Podman ang mina-manage nito. Inalis ang lumang Docker module ilang taon na ang nakalipas at hindi na ito ibabalik. Kung tumatakbo sa Docker ang iyong mga serbisyo, i-manage ang mga ito gamit ang compose file na nasa version control sa pamamagitan ng SSH, at hayaang i-handle ng Cockpit ang system sa paligid ng mga ito, gaya ng journal at mga disk.