Cockpit mi Webmin mi: Sunucu Yönetimi Karşılaştırması

Cockpit ve Webmin: kısa cevap

Cockpit ve Webmin, bir Linux sunucusunu tarayıcı üzerinden yönetmek için kullanılan web panelleridir ve farklı ihtiyaçlara yanıt verirler. Cockpit, dağıtımınızın kendi deposunda yerleşik olarak gelir ve makineyi systemd, journald, polkit ve udisks aracılığıyla okur; dolayısıyla size hâlâ SSH üzerinden yönettiğiniz bir sunucuyu gösterir. Webmin daha eskidir ve kapsamı çok daha geniştir: Cockpit'in hiç dokunmadığı Apache, BIND, Postfix, MariaDB ve düzinelerce diğer servis için yapılandırma dosyalarını doğrudan yazar ve bunu yapmak için root yetkileriyle kendi web sunucusunu çalıştırır.

Tek bir sunucunun canlı durumunu izlemek, günlük kayıtlarını okumak ve acil durum terminaline erişmek istediğinizde Cockpit kurun. Elle yapılandırmak istemediğiniz bir servis için form tabanlı bir düzenleyiciye ihtiyaç duyduğunuzda Webmin kurun. Her ikisini de parola girişiyle halka açık bir port üzerinde çalıştırmayın. Eğer hâlihazırda ikiden veya üçten fazla sunucu yönetiyorsanız, dürüst cevap genellikle ikisinin de kullanılmamasıdır; SSH ve Ansible ikilisi, herhangi bir panelden çok daha iyi ölçeklenir.

Her panelin neleri değiştirebildiği

Cockpit'in temel kurulumu küçüktür ve çoğu alan, dahil etmeyebileceğiniz ayrı paketlerden oluşur:

• systemd servisleri ve zamanlayıcıları: başlatma, durdurma, etkinleştirme ve unit dosyasını okuma
• journalctl ile tarih seçici içeren, birim ve önceliğe göre filtrelenmiş günlük kayıtları (journal)
• yerel hesaplar, grup üyelikleri ve yetkilendirilmiş SSH anahtarları
• cockpit-storaged ile depolama: bölümler, LVM birim grupları, dosya sistemleri ve bağlama noktaları
• yalnızca Podman yöneten cockpit-podman ile konteynerler
• cockpit-packagekit ile paket güncellemeleri
• cockpit-pcp ile CPU, bellek, disk ve ağ grafikleri
• tarayıcı sekmesinde bir root terminali

Ubuntu VPS üzerinde iki alan bozuk görünür ancak aslında bozuk değildir. Cockpit'in Ağ sayfası NetworkManager için bir arayüzdür; Ubuntu sunucu imajları ise systemd-networkd ile netplan kullandığından bu sayfa eksik veya boştur. Bu sayfayı geri getirmek için uzak bir sunucuya NetworkManager kurmayın; çünkü bu servis arayüzü devralır ve yapılacak bir hata SSH oturumunuzu kaybetmenize neden olur. Cockpit'in güvenlik duvarı kontrolleri firewalld için bir arayüzdür; Ubuntu ise ufw kullandığından hiçbir güvenlik duvarı kontrolüne sahip olmazsınız. sudo ufw status komutunu terminalde çalıştırmaya devam etmelisiniz.

Webmin, tek bir programdan ziyade servis bazlı modüllerin bir koleksiyonu olduğu için çok daha geniş bir alanı kapsar:

• formlar aracılığıyla Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL ve Samba yapılandırması
• kullanıcılar, gruplar ve disk kotaları
• cron işleri ve sistem saati
• paket güncellemeleri ve yükleme/indirme özellikli bir dosya yöneticisi
• iptables ve firewalld için olanlar dahil olmak üzere güvenlik duvarı arayüzleri
• yapılandırma dosyası yedekleri ve bir değişiklik yapıldığında bunu diğer Webmin sunucularına ileten kümeleme modülleri

Webmin, /etc altındaki gerçek dosyaları düzenler. Formların arkasında gizli bir veritabanı yoktur; bu nedenle /etc sürüm kontrolü altındaysa, bir formu kaydettikten sonra sudo git -C /etc diff komutunu çalıştırmak, modülün tam olarak ne yazdığını gösterir. Herhangi bir Webmin sayfasının gerçekte ne yaptığını öğrenmenin en hızlı yolu budur. Webmin kurulumu ve ilk giriş kılavuzu, modül ağacını ayrıntılı olarak inceler. Virtualmin ve Usermin, paylaşımlı barındırma ve son kullanıcılar için aynı motor üzerine inşa edilmiş ayrı ürünlerdir ve burada maruziyet hakkında söylenen her şeyi miras alırlar.

Kimlik doğrulama yöntemleri

Cockpit'in kendine ait bir kullanıcı veritabanı yoktur. Giriş sayfası /etc/pam.d/cockpit içindeki PAM (pluggable authentication modules) yığınını çalıştırır; bu nedenle hesaplarınız Unix hesaplarınız, parolalarınız ise Unix parolalarınızdır. /etc/cockpit/disallowed-users dosyası root kullanıcısını listelediği için root girişi varsayılan olarak reddedilir. Ayrıcalıklı işlemler polkit üzerinden yürütülür ve arayüz, herhangi bir değişiklik yapmadan önce parolanızı tekrar ister; bu yüzden yetki yükseltme yapana kadar sayfa başlığında "Sınırlı erişim" ifadesi görülebilir.

Bu tasarımın, güvenlik düzeyi artırılmış sunucularda karşılaşılan bir sonucu vardır. Eğer parola kimlik doğrulaması devre dışı bırakılmış anahtar tabanlı SSH girişi adımlarını izlediyseniz, hesabın kullanılabilir bir parolası olmayabilir; bu durumda ssh çalışmaya devam etse de Cockpit girişi reddedilir. Durumu sunucu üzerinde kontrol edin:

sudo passwd -S deploy

deploy L ile başlayan çıktı, parolanın kilitli olduğu anlamına gelir; bu durumda PAM'in kabul edebileceği bir veri yoktur ve girdiğiniz hiçbir parola çalışmaz. P ise kullanılabilir bir parolanın ayarlı olduğunu gösterir. Cockpit'in kendi giriş sayfası SSH anahtarlarını kabul etmez. Anahtarlar yalnızca Cockpit, giriş yaptığınız makineden başka bir ana bilgisayara bağlandığında kullanılır.

Webmin, kullanıcılarını /etc/passwd'ten ayrı olarak /etc/webmin/miniserv.users içinde tutar; ayrıca Unix hesaplarına karşı kimlik doğrulaması yapacak şekilde yapılandırılabilir. Tüm modüllere erişim izni verilen bir Webmin kullanıcısı, giriş kabuğu ne olursa olsun o makinede root yetkisine sahiptir. Webmin, kendi TOTP (time-based one-time password) desteği ve hatalı giriş denemelerinden sonra ana bilgisayarları engelleme özelliği ile gelir; her ikisi de Webmin Configuration içinden açılabilir. Cockpit'e ikinci bir doğrulama faktörü eklemek için, örneğin libpam-google-authenticator kullanarak PAM'e bir modül eklemeniz gerekir.

Her birinin güncellenme yöntemi

Cockpit, dağıtımınız tarafından paketlenir. Ubuntu 24.04 üzerinde arşivden gelir; ancak upstream projesi, daha yeni bir sürüm için backports deposunun kullanılmasını önerir:

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

apt policy, yüklü sürümü ve geldiği depoyu yazdırır. Eğer backports içinde daha yeni bir sürüm yoksa, apt otomatik olarak arşiv sürümüne döner; bu durum bir sorun teşkil etmez. cockpit.socket çıktısı active (listening) şeklinde görünmelidir. Güvenlik yamaları, çekirdeğinizle aynı unattended-upgrades komutu üzerinden, zaten güvendiğiniz bir yayıncı tarafından sunulur.

Webmin, Ubuntu arşivinde yer almaz. Resmi kurulum süreci, önce Webmin'in kendi deposunu ve imzalama anahtarını ekler:

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

Bu betiği çalıştırmadan önce okuyun, çünkü root yetkileriyle çalışır. Bu noktadan itibaren sunucudaki her apt upgrade komutu, Webmin deposundan da veri çeker; böylece sunucunuz üzerinde root seviyesinde güvene sahip ikinci bir yayıncı eklemiş olursunuz. Webmin'in gerçek maliyeti budur ve bu durum net bir örneği hak eder: CVE-2019-15107, 1.9x sürümlerindeki çeşitli paketlerde bulunan ve kimlik doğrulaması gerektirmeyen komut çalıştırma imkanı veren bir arka kapıydı. Bu açık, kaynak deposundan değil, projenin derleme sunucusunun ele geçirilmesi nedeniyle kullanıcılara ulaştı. Dağıtım paketlemesi bu tür durumları imkansız kılmaz. Ancak, sizin bizzat yönetmediğiniz bir derleme ve inceleme aşamasını sürece dahil eder.

Neden her ikisi de genel bir portta bulunmamalıdır

Cockpit TCP 9090, Webmin ise TCP 10000 portunu dinler; her ikisi de kendinden imzalı bir sertifika ile TLS (taşıma katmanı güvenliği) üzerinden çalışır, bu nedenle tarayıcıda gördüğünüz ilk şey bir uyarıdır. Kendinden imzalı sertifika oluşturma ve güvenme bölümü, bu uyarının neyi ifade edip neyi etmediğini açıklar. Her iki port da sürekli taranır ve her iki panel de root yetkilerine erişim sağlar; bu nedenle tahmin edilen veya yeniden kullanılan bir parola, sunucunun tamamen ele geçirilmesine yol açar.

Güvenli yöntem, paneli localhost adresine bağlamak ve ona bir SSH tüneli üzerinden erişmektir. Cockpit için socket birimini geçersiz kılın:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

Satır başındaki boş ListenStream= ifadesi gereklidir. systemd, liste ayarlarını mevcut değerlere ekler; bu ifade olmadan birim orijinal 0.0.0.0:9090 değerini korur ve yeni adresi buna ekler, böylece paneliniz genel erişime açık kalmaya devam eder. Geçersiz kılma işlemini uygulayın ve dinlenen portları kontrol edin:

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

Çıktı 127.0.0.1:9090 değerini göstermelidir. *:9090 veya 0.0.0.0:9090 adresi, geçersiz kılma işleminin etkili olmadığını gösterir. Şimdi kendi makinenizden tüneli açın ve https://localhost:9090 adresine gidin:

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

Yerel portu uzak port ile aynı tutun. Cockpit, tarayıcının Origin başlığını, hizmet verdiğini varsaydığı adresle karşılaştırır; bu nedenle 9999 gibi farklı bir yerel porttan açılan tünel giriş sayfasını yükler ancak giriş aşamasında hata verir ve journalctl -u cockpit reddedilen kaynağı kaydeder. Farklı bir yerel port kullanmanız gerekiyorsa, bunu /etc/cockpit/cockpit.conf içinde belirtin:

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

Değişikliği uygulamak için sudo systemctl restart cockpit.socket ile yeniden başlatın. Webmin için eşdeğer ayar /etc/webmin/miniserv.conf dosyasında bulunur:

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 ayrıca form gönderimlerinde Referer başlığını kontrol eder ve başka bir ana bilgisayardan geliyormuş gibi görünen istekleri reddeder; reverse proxy ile yapılan ilk denemelerin başarısız olma nedeni budur. Aynı dosyadaki referers= satırı, proxy'nin ana bilgisayar adını izin verilenler listesine eklediğiniz yerdir; webprefix= ise Webmin'e belirli bir yol altında çalıştığını bildirdiğiniz yerdir.

Kimlik doğrulamalı bir reverse proxy diğer seçenektir: ön tarafta nginx ve giriş işlemini gerçekleştiren bir Authentik tek oturum açma katmanı. Bu yöntem çalışır ancak ikinci en iyi seçenektir. Panel hala proxy arkasında root olarak çalışır ve artık bir yerine iki giriş kapısını yönetmeniz gerekir. Bir SSH tüneli ise internete açık hiçbir dinleme servisi eklemez ve halihazırda koruduğunuz SSH anahtarınızı yeniden kullanır.

Hali hazırda üretim servislerini çalıştıran bir sunucuda hangi panel kullanılmalı

Cockpit, başkalarının makineye bağımlı olduğu durumlarda önem taşıyan iki nedenden dolayı tercih edilmelidir. Soket tabanlı etkinleştirme özelliğine sahiptir; bu sayede cockpit-ws yalnızca bir oturum açık olduğunda çalışır ve bir port üzerinde bekleyen kalıcı bir root daemon bulunmaz. Ayrıca hiçbir yapılandırmaya sahip değildir: paketi kaldırdığınızda Cockpit kendi yapılandırmasını saklamadığı için tüm servisler olduğu gibi çalışmaya devam eder. Webmin'in miniserv.pl süreci, oturum açan biri olsun ya da olmasın bellekte kalmaya devam eder. Çalışan sürecin bellekte kapladığı alanı gösteren systemctl status webmin komutu ile maliyetini kontrol edebilirsiniz.

Webmin'in DNS veya e-posta modüllerine ihtiyaç duyuyorsanız, bunları ayrı bir sunucuda barındırın. Yalnızca tek bir iş yapan ve 127.0.0.1 adresine bağlı bir Webmin sunucusu, sınırlı bir risk teşkil eder. Webmin'in müşteri odaklı uygulamanızla aynı sunucuyu paylaşması ise risklidir. Her iki panelden birini kurmadan önce temel hazırlıkları yapın: yeni bir VPS üzerindeki ilk on dakika rehberi, her iki panelin de halihazırda mevcut olduğunu varsaydığı root olmayan kullanıcı ve güvenlik duvarı yapılandırmasını kapsar.

Cevap ikisi de olmadığında

Panel kullanımı sunucu bazlı ve manuel bir işlemdir; neyin, neden değiştiğine dair bir kayıt bırakmaz. Tek bir sunucu için bu kabul edilebilir. Beş sunucuda kendinizi tekrar etmeye başlarsınız, yirmi sunucuda ise hangi sunucunun değişikliği almadığını tahmin etmeye çalışırsınız. Cockpit, SSH üzerinden tek bir oturuma başka sunucular ekleyebilir ancak güncel sürümler bunu varsayılan olarak devre dışı bırakır ve AllowMultiHost=yes ile /etc/cockpit/cockpit.conf üzerinde işlem yapılmasını ister; bu da aynı değişikliği beş kez tıklamanız gerektiği gerçeğini değiştirmez.

Bunun alternatifi, yapılandırmalarınızı bir git deposunda tuttuğunuz standart SSH kullanımıdır. Birden fazla Linux sunucusunu tek bir merkezden yönetmek bu kurulumun yapısını ele alır ve ilk Ansible playbook rehberi, aynı güvenlik duvarı kuralını, diff olarak inceleyebileceğiniz tek bir dosyadan tüm sunuculara uygulamanızı sağlar. Container çalışmaları için de aynı yöntem geçerlidir: Docker Compose temel rehberi içerisinde anlatıldığı gibi, git üzerindeki bir dosyadan SSH aracılığıyla docker compose up -d çalıştırmak, herhangi bir panelde tıklama yapmaktan daha verimlidir; ayrıca Cockpit zaten Docker yönetimi sunmaz.

Paneli, terminalin zayıf kaldığı metrik grafiklerini okumak veya kırk birimden hangisinin hata verdiğini tespit etmek gibi işler için kullanın. İkiden fazla kez yapacağınız her işlem için ise kod kullanın.

Hata modları ve karşılaşacağınız dizgeler

Cockpit, SSH'in kabul ettiği bir parolayı reddediyor. Hesap yalnızca anahtar (key-only) ile erişime açıktır. sudo passwd -S alice ikinci alanda L çıktısını verir, bu nedenle PAM'in kontrol edeceği bir parola yoktur. sudo passwd alice ile bir parola belirleyin veya o hesabı sadece SSH için kullanıp Cockpit'e başka bir kullanıcıyla giriş yapın.

Cockpit, doğru parola girilmesine rağmen root girişini reddediyor. /etc/cockpit/disallowed-users, root listeler. Sudo yetkilerine sahip normal bir kullanıcı ile giriş yapın. Öngörülen yöntem budur; çünkü polkit bu sayede hangi kullanıcının yetki yükselttiğini kayıt altına alır.

Cockpit üzerinde Ağ veya Güvenlik Duvarı sayfaları görünmüyor. Bu sayfalar NetworkManager ve firewalld servislerine ihtiyaç duyar. Bir Ubuntu VPS, systemd-networkd ve ufw ile birlikte netplan çalıştırdığından bu sayfalar görüntülenmez. Sistemde bir arıza yoktur; çözüm, SSH üzerinden ufw kullanmaya devam etmektir.

Cockpit giriş sayfası tünel üzerinden yükleniyor ancak giriş başarısız oluyor. Yerel portunuz uzak porttan farklıdır, bu nedenle Origin kontrolü başarısız olur ve journalctl -u cockpit bunu gösterir. Portları eşleştirin veya /etc/cockpit/cockpit.conf içerisinde Origins ayarını yapın.

Webmin form gönderimleri, bir proxy arkasına alındıktan sonra başarısız oluyor. Referer kontrolü bu gönderimleri reddeder. Proxy ana bilgisayar adını /etc/webmin/miniserv.conf içindeki referers= kısmına ekleyin ve panel bir yol (path) altında sunuluyorsa webprefix= ayarını yapın.

Bir panelin dış dünyaya açık olup olmadığından emin değilsiniz. sudo ss -lntp | grep -E '9090|10000' bu soruyu sunucunun kendisinden yanıtlar ve Webmin her giriş denemesini /var/webmin/miniserv.log dosyasına yazar; dinleme ayarlarında yapılan herhangi bir değişiklikten sonra bu dosyayı okumak faydalıdır.

FAQ

Tek bir Ubuntu VPS için Cockpit mi yoksa Webmin mi daha iyidir?

Çoğu kullanıcı için Cockpit daha uygundur; çünkü Ubuntu'nun kendi depolarından gelir, sistemin geri kalanıyla birlikte güncellenir ve yalnızca tarayıcı oturumu açıkken çalışır. BIND veya Postfix gibi Cockpit'in desteklemediği servisler için form tabanlı bir düzenleyiciye ihtiyaç duyduğunuzda Webmin'i tercih edebilirsiniz. Ancak bu durumda, Webmin'in web sunucusunun sürekli root yetkisiyle çalıştığını ve güncellemelerin Webmin'in kendi deposundan geldiğini kabul etmeniz gerekir.

Aynı sunucuda hem Cockpit hem de Webmin çalıştırabilir miyim?

Evet. Farklı portları (9090 ve 10000) kullandıkları için çakışmazlar; her biri sistemi sahiplenmek yerine doğrudan düzenler. Yine de bu önerilen bir yöntem değildir. Her panel, aynı makinede root yetkisine sahip ayrı bir giriş noktasıdır; dolayısıyla birkaç tıklama tasarrufu yapmak için güvenlik riskinizi ikiye katlamış olursunuz. Her ikisini de kuracaksanız, her ikisini de 127.0.0.1 adresine bağlayın ve bunlara bir SSH tüneli üzerinden erişin.

9090 veya 10000 numaralı portları internete açmak güvenli midir?

Parola ile giriş yapılıyorsa güvenli değildir. Her iki panel de root yetkisine erişim sağlar ve her iki port da açıldıktan sonraki birkaç saat içinde rutin taramalarla tespit edilir. Paneli 127.0.0.1 adresine bağlayın, ardından ssh -N -L 9090:127.0.0.1:9090 user@host komutunu çalıştırın ve https://localhost:9090 adresine gidin. sudo ss -lntp | grep 9090 ile doğrulama yapın; bu komut 0.0.0.0:9090 yerine 127.0.0.1:9090 çıktısını vermelidir. Kimlik doğrulaması gerektiren bir reverse proxy, kabul edilebilir ikinci bir seçenektir.

SSH anahtarı ile giriş yapabildiğim halde Cockpit girişlerim neden başarısız oluyor?

Cockpit, PAM üzerinden Unix parolası ile kimlik doğrulaması yapar ve giriş sayfasında SSH anahtarlarını kabul etmez. Güvenliği artırılmış bir sunucuda, kullanıcı hesabının genellikle kullanılabilir bir parolası yoktur. sudo passwd -S youruser komutunu çalıştırın: ikinci alandaki L ifadesi parolanın kilitli olduğu anlamına gelir; bu durumda PAM'in kabul edebileceği bir parola yoktur ve tüm denemeler reddedilir. sudo passwd youruser ile bir parola belirleyin veya panel için farklı bir hesap kullanın.

Cockpit, Docker container'larını yönetebilir mi?

Hayır. Cockpit'in container sayfası cockpit-podman paketinden gelir ve Podman'i yönetir. Eski Docker modülü yıllar önce kaldırılmıştır ve geri gelmeyecektir. Servisleriniz Docker üzerinde çalışıyorsa, bunları SSH üzerinden sürüm kontrolüne alınmış bir compose dosyası ile yönetin; Cockpit'in ise journal ve diskler gibi sistemin geri kalanıyla ilgilenmesini sağlayın.