Herkese selamlar,

Eğer elinizde birden fazla VMware ESXi host varsa ve lisans süreleri (Evaluation) dolmak üzereyse ya da yeni lisanslar atamanız gerekiyorsa her bir sunucuya tek tek SSH veya web arayüzü ile bağlanıp lisans girmek bir süre sonra çileye dönüşüyor.

VMware'in sunduğu esxcli komut seti sayesinde, ESXi ana makinelerine arayüze bile girmeden, doğrudan SSH üzerinden (veya bir bash script ile toplu halde) lisans anahtarını saniyeler içinde tanımlayabilirsiniz.

ESXi komut satırından lisans sorgulama, yeni lisans ekleme ve mevcut lisansı güncelleme adımlarını sizlerle paylaşıyorum.

Adım Adım ESXCLI ile Lisans Yönetimi:

1. Adım: Sunucuya SSH ile Bağlanın

Öncelikle lisans gireceğiniz ESXi ana makinesine root yetkileriyle SSH üzerinden bağlanın:

Bash

Kod 
Yığını:
ssh root@<esxi_host_ip_adresi>

2. Adım: Mevcut Lisans Durumunu Kontrol Edin

Yeni lisans girmeden önce sunucunun üstündeki mevcut lisansın durumunu, sürümünü ve bitiş tarihini görmek için şu komutu çalıştırın:

Bash

Kod 
Yığını:
esxcli software licenses summary get

Bu komut size sunucunun lisanslı olup olmadığını, hangi özelliklerin (vMotion, High Availability vb.) aktif olduğunu ve kalan süreyi özet olarak verecektir.

3. Adım: Yeni Lisans Anahtarını Ekleyin (Ana Olay)

Eğer sunucuda hiç lisans yoksa veya mevcut lisansı yenisiyle değiştirecekseniz, esxcli software licenses add komutunu kullanıyoruz.

Komutun genel yapısı şöyledir:

Bash

Kod 
Yığını:
esxcli software licenses add -s <BURAYA_25_HANELI_LISANS_ANAHTARINI_YAZIN>

Bash

Kod 
Yığını:
esxcli software licenses add -s AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Komutu çalıştırdıktan sonra başarılı olduğuna dair bir çıktı (License successfully added... benzeri) dönecektir.

4. Adım: Lisansın Atandığını ve Özellikleri Doğrulayın Lisansı ekledikten sonra doğru oturup oturmadığını ve tüm ESXi özelliklerinin kilidinin açılıp açılmadığını kontrol etmek için tekrar özet komutunu çalıştırabilirsiniz:

Bash

Kod 
Yığını:
esxcli software licenses summary get

Eğer lisans anahtarı doğru formatta ve sürümle uyumluysa, değerlendirme (evaluation) süresi kalkacak ve lisanslı kalıcı sürüm ekranda görünecektir.

Ağınızda 10-20 tane ESXi host varsa, bir text dosyasına host IP'lerini alt alta yazıp, ufak bir SSH döngüsü (for loop) ile bu komutu tek seferde bütün sunuculara basabilirsiniz:

Bash

Kod 
Yığını:
for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do
  ssh root@$ip "esxcli software licenses add -s AAAAA-BBBBB-CCCCC-DDDDD-EEEEE"
  echo "$ip hostuna lisans eklendi!"
done

Web arayüzünün yavaşlığıyla uğraşmadan, esxcli komutları ile bu işi saniyeler içinde halledebilirsiniz. Özellikle otomasyon ve toplu sunucu kurulumlarında bu yöntem hayat kurtarır.

Umarım işinize yarar. Farklı bir VMware otomasyon sorunuz veya komut ihtiyacınız varsa aşağıda tartışabiliriz, iyi çalışmalar!

Herkese selamlar,

Bugün sizler ile SolusVM 2.0 altyapısı kullanan sysadmin'lerin veya VDS yöneticilerinin zaman zaman karşılaştığı yaygın krizlerden biri olan sanal sunucuya normal yollarla (SSH, RDP) erişilemediği anlarda VNC ekranının da siyah ekranda kalması ya da "Connection refused / Timeout" hatası vermesi durumundan bahsedeceğim. Özellikle ağ yapılandırması bozulduğunda veya güvenlik duvarı tıkandığında paneldeki standart noVNC bağlantısı kopabilir.

Böyle bir senaryoda kontrol paneli (master) üzerinden çözüme ulaşılamadığı durumlarda doğrudan Node (Hypervisor) konsolu üzerinden tünel oluşturarak noVNC oturumunu ayağa kaldırmak, sistemi kurtarmak için en net yöntemdir.

Teknik Altyapı ve Sorunun Kök Nedeni: SolusVM 2.0 mimarisinde kontrol paneli ile node'lar arasında API ve WebSocket tabanlı bir iletişim yürütülür. VDS konsol talebi geldiğinde node üzerindeki ilgili QEMU/KVM socket'i ile panel arasında bir noVNC tüneli oluşturulur.

Şu durumlarda ise tünel kopabilir:

• Node üzerindeki WebSocket veya proxy servislerinin (örneğin solusvm2 servisleri) anlık kilitlenmesi.
• VDS'in içindeki ağ servislerinin (iptables/ufw veya netplan) tüm trafiği kesmesi sebebiyle VNC portlarının yanıt vermemesi.
• Node ile kontrol paneli arasındaki API portlarında yaşanan anlık SSL/sertifika senkronizasyon kopuklukları.

Bu tarz bir kopma yaşadığınızda aşağıdaki adımları uygulayarak noVNC tünelini ve konsolu yeniden toparlayabilirsiniz;

Eğer panelden VNC açılmıyorsa ve müdahale etmeniz gerekiyorsa node sunucusuna SSH ile bağlanarak şu adımları izleyebilirsiniz:

1. Adım: İlgili Sanal Makinenin (VDS) UUID Değerini Bulun Öncelikle sorun yaşadığımız sanal sunucunun SolusVM 2.0 sistemindeki benzersiz kimliğini (UUID) tespit etmemiz gerekiyor. Node sunucusuna bağlanıp aktif KVM domainlerini listeleyin:

Bash

Kod 
Yığını:
virsh list --all

(Burada erişilemeyen sunucunun domain name veya UUID değerini göreceksiniz. Örnek olarak makinenin libvirt üzerindeki adını aldığımızı varsayalım.)

2. Adım: VNC Portunu ve Socket Durumunu Kontrol Edin Söz konusu sanal makinenin hangi VNC portunu dinlediğini veya socket hatası verip vermediğini şu komutla sorgulayın:

Bash

Kod 
Yığını:
virsh vncdisplay <sunucu_adi_veya_uuid>

Bu komut size genellikle :0, :1 gibi bir değer veya doğrudan bir port numarası (5900, 5901 vb.) döndürecektir. Eğer port kapalıysa QEMU süreci askıda kalmış demektir.

3. Adım: QEMU / VNC Servisini Yeniden Başlatma veya Zorlama Eğer VNC soketi yanıt vermiyorsa, sanal makineyi kapatıp açmadan (hard reset atmadan) VNC socket'ini tetiklemek için libvirt yapılandırmasını tazeleyebiliriz ya da node üzerindeki solusvm2 agent servisini kontrol edebiliriz:

Bash

Kod 
Yığını:
# SolusVM 2 node agent servisini yeniden başlatma
systemctl restart solusvm-agent

(Bu servis yeniden başladığında panel ile node arasındaki tünel istekleri sıfırdan kurulur ve noVNC kuyruğu temizlenir.)

4. Adım: Manuel Tünel Oluşturma (SSH Port Forwarding Yöntemi) Eğer web panelindeki noVNC arayüzü hâlâ yüklenmiyorsa, kendi yerel bilgisayarınızdan node sunucusu üzerinden doğrudan VNC portuna bir SSH tüneli (port forwarding) açarak tarayıcınızdan bağlanabilirsiniz.

Yerel terminalinizden şu komutu girin:

Bash

Kod 
Yığını:
ssh -L 5900:127.0.0.1:5900 root@<node_sunucu_ip_adresi>

(Not: Node üzerindeki QEMU VNC portunu yukarıdaki virsh vncdisplay komutundan aldığınız porta göre 5900, 5901 şeklinde güncelleyebilirsiniz.)

Bu tünel kurulduktan sonra herhangi bir VNC istemcisi (TigerVNC, TightVNC vb.) kullanarak 127.0.0.1:5900 adresine bağlanabilir sunucunun fiziksel ekranına doğrudan erişebilirsiniz.

SolusVM 2.0 mimarisinde bu tarz krizlerle karşılaşıldığında panik yapıp sanal sunucuyu doğrudan kapatmak veri kaybına yol açabilir. Node seviyesinde virsh komutları ve SSH tünelleme yöntemiyle sisteme sızmak, veriyi kurtarmak veya ağ yapılandırmasındaki hatayı (/etc/netplan vb.) düzeltmek için en güvenli yoldur.

Umarım bu teknik inceleme, benzer altyapı sorunları yaşarsanız işinizi kolaylaştırır. Konuyla ilgili eklemek istedikleriniz veya farklı bir çözüm yönteminiz varsa aşağıda tartışabiliriz.

İyi çalışmalar.

Herkese selamlar,

Geçen gün projelerimden birinde yedekleme yaparken Nginx tarafında aniden şu hatayla karşılaştım;

413 Request Entity Too Large

Muhtemelen birçoğunuzun başına gelmiştir. Özellikle WordPress sitelere büyük eklentiler yüklerken vs. Nginx 1mb üstünde yükleme/yedekleme isteklerini doğrudan reddediyor.

Araştırıp çözümü uyguladım, belki kafayı sıyıran başkaları vardır diye adımları şuraya net bir şekilde bırakıyorum. İşinize yaraması dileğiyle.

1. Konfigürasyon Dosyasını Açın SSH üzerinden sunucunuza bağlanın ve Nginx ana yapılandırma dosyasını açın

Bash

Kod 
Yığını:
nano /etc/nginx/nginx.conf

2. client_max_body_size Değerini Ekleyin

Dosya içerisindeki http { }, server { } veya location { } bloklarından uygun olanının içine 1m ise 1m ya da 100m ise 100m şeklinde ekleyin

Nginx

Kod 
Yığını:
http {
    # Diğer ayarlarınız burada bulunur...
    
    client_max_body_size 100M;
}

3. PHP Kullanıyorsanız (PHP-FPM / FastCGI) Dikkat!

Sadece Nginx'i ayarlamak yetmeyebilir. Ben arka planda PHP çalıştırdığım için PHP'nin de kendi içinde dosya yükleme sınırları varmış. İlk etapta onları güncellemediğim için farklı hatalar aldım. Daha sonrasında güncelleme sağladım

İlgili php.ini dosyanızı açın:

Bash

Kod 
Yığını:
nano /etc/php/8.x/fpm/php.ini  *(Kendi PHP sürümünüze göre yolu düzenleyin)*

Şu iki değeri bulup aynı boyuta (örneğin 100m) getirin

Ini, TOML

Kod 
Yığını:
upload_max_filesize = 100M
post_max_size = 100M
memory_limit = 256M

4. Servisleri Yeniden Başlatın

Ayarlayı yaptıktan sonra Nginx ve PHP-FPM servislerine restart atalabilirsiniz

Bash

Kod 
Yığını:
# Nginx test ve yeniden başlatma
nginx -t
systemctl restart nginx

# PHP-FPM yeniden başlatma (Sürümünüze göre 8.1, 8.2, 8.3 vs. yazabilirsiniz)
systemctl restart php8.2-fpm

Epey araştırdım ama kesinlikle değdi. Umarım birilerinin gecenin bir yarısı hayatını kurtarır. Takıldığınız bir yer olursa aşağıdan sorabilirsiniz, iyi çalışmalar.