Herkese selamlar,

Geçen gün e-ticaret altyapısında sunuculardan birinde çok garip bir şikayet aldım. Müşteriler "Şifremi Unuttum" butonuna bastıktan sonra mail ya hiç gelmiyor ya da 2-3 saat sonra geliyormuş. Bu süre zarfında adamlar alışveriş sepetini terk edip başka siteye gitmiş oluyor.

SSH ile sunucuya bağlanıp mail loglarını (/var/log/mail.log) açtığımda Postfix kuyruğu (queue) dolup taşmış. Binlerce bilgilendirme maili, bülten veya bildirim önde yığılmış. Şifre sıfırlama gibi kritik ve acil mailler de o kuyruğun en arkasında saatlerce beklemiş.

Bu kronik sorunu Postfix tarafında nasıl çözdüğümü ve acil mailleri önceliğe alacak şekilde kuyruk mimarisini nasıl düzenlediğimi sizlere anlatacağım. Bilhassa E-ticaret veya üyelikli site yönetenler inceleyebilirler.

Varsayılan ayarlarda Postfix, kendisine gelen tüm mailleri tek bir kuyruğa (active queue) yığı ve "ilk gelen ilk çıkar" (FIFO - First In, First Out) mantığıyla sırayla gönderir.

• Eğer siteniz toplu mail (bülten, promosyon) atıyorsa veya spam/gecikmeli yanıt veren dış sunuculara mail gönderiyorsa, Postfix o mailleri göndermeye çalışırken kilitlenir.
• Şifre sıfırlama veya sipariş onay mailli gibi "kritik" olması gereken işlemler de o koca kuyrukta arkada sıra bekler.

Bu sorunu kökten çözmek için Postfix konfigürasyonunu optimize edip ve kuyruk yönetimini tazeledim.

1. Adım: Kuyruktaki Yığılmayı ve Durumu Kontrol Etme

Öncelikle sunucunuzda şu an kuyrukta kaç tane mail beklediğini görmek için şu komutu çalıştırın;

Kod 
Yığını:
mailq

Eğer ekranda binlerce satır akıyorsa ve Connection timed out veya Deferred statüsünde mailler birikmişse kuyruk tıkanmış demektir.

2. Adım: Postfix Ana Konfigürasyonunu Düzenleme (main.cf)

Postfix'in kuyruk yönetimini hızlandırmak ve tıkanıklıkları önlemek için /etc/postfix/main.cf dosyasını açıyoruz;

Kod 
Yığını:
nano /etc/postfix/main.cf

Dosyanın uygun bir yerine şu performans parametrelerini ekleyin veya güncelleyin:

Ini, TOML

Kod 
Yığını:
# Eşzamanlı maksimum bağlantı sayısını artırarak gönderimi hızlandırır
default_destination_concurrency_limit = 20
initial_destination_concurrency = 10

# Mesaj kuyruğunu işleme sıklığını artırıyoruz (varsayılanlar yavaştır)
queue_run_delay = 300s
minimal_backoff_time = 180s
maximum_backoff_time = 4000s

# TCP bağlantı zaman aşımı sürelerini düşürerek yanıt vermeyen sunucularda takılı kalmayı önler
smtp_connect_timeout = 30s
smtp_helo_timeout = 30s

3. Adım: Kritik Mailler İçin Ayrı Bir Postfix Instance Kurulumu

Büyük e-ticaret sitelerinde toplu mailler ile şifre sıfırlama mailleri asla aynı kuyruktan atılmaz. Bunun için Postfix'e ikinci bir instance (bağımsız port/kanal) kurarak şifre sıfırlama maillerini direkt Mailbaby veya harici bir SMTP relay üzerinden anında gönderecek şekilde ayırabilirsiniz.

Eğer tek sunucu üzerinden yürüyecekseniz, mevcut kuyruğu temizlemek için şu komutu kullanabilirsiniz:E-ticaret sitelerinden giden şifre sıfırlama maillerinin saatlerce gecikme sorununu çözdümE-ticaret sitelerinden giden şifre sıfırlama maillerinin saatlerce gecikme sorununu çözdüm

Kod 
Yığını:
# Kuyruktaki tüm bekleyen (deferred) mailleri zorla tekrar göndermeyi tetikle
postqueue -f

4. Adım: PHP / E-Ticaret Yazılımı Tarafı (Asenkron Kuyruk - Queue)

Sadece Postfix değil, e-ticaret yazılımınızın mail gönderirken PHP'yi kitlememesi gerekir.

• Mail gönderimlerini doğrudan tarayıcı isteği (HTTP request) sırasında synchronous (senkron) yapmak yerine, Cron veya Redis/Beanstalkd tabanlı asenkron kuyruk sistemlerine (Background Processing) devredin. Böylece site arayüzü mail sunucusunun yanıt vermesini beklemez, mail arka planda anında kuyruğa alınır.

Bu optimizasyonlar yapıldıktan sonra şifre sıfırlama maillerindeki o gecikmeler tamamen ortadan kalktı ve mailler saniyeler içinde kullanıcıların kutusuna düşmeye başladı.

Herkese iyi forumlar,

VMware ESXi altyapılarında büyük boyutlu sanal makineleri klonlarken, taşırken veya snapshot oluşturup silerken sunucuların bir anda anlık takılmalara girdiğini, IOPS değerlerinin tavan yaptığını ve ESXi host'un CPU'sunun sömürüldüğünü muhtemelen birçoğunuz yaşamışsınızdır.

Bunun temel sebebi bu ağır depolama operasyonlarının varsayılan olarak ESXi ana makinesinin işlemcisi ve yazılımı üzerinden yapılmasıdır. Bu noktada VAAI teknolojisini kullanmaya başladım. Depolama donanımınız destekliyorsa bu yükü host'tan alıp doğrudan storage cihazının kendisine (NAS/SAN) yıkabilirsiniz.

ESXi üzerinde VAAI özelliklerinin kapalı kaldığını fark edip nasıl aktif ettiğimi ve sistemin nasıl rahatladığını bir rehber niteliğinde sizler için rehber niteliğinde anlatacağım. Benzer altyapı yönetenlerin kesinlikle göz atabilirler.

VAAI etkinleştirildiğinde şu 4 temel donanımsal hızlandırma aktif oluyor;

1. Atomic Test and Set (ATS): Kilitlenme sürelerini azaltarak çoklu VM operasyonlarını hızlandırır.
2. Block Zero / Write Same: Depolama üzerinde sıfırlama işlemlerini donanıma yaptırır.
3. Block Copy / Full Copy: Klonlama ve migration işlemlerini ESXi RAM'ini yormadan storage içinde çözer.
4. Thin Provisioning Stun / Space Reclamation: Boşalan alanların depolamaya geri kazandırılmasını sağlar.

1. Adım: Depolama Cihazınızın VAAI Desteğini Kontrol Edin

Öncelikle kullandığınız SAN/NAS veya fiziksel disk altyapısının VAAI destekleyip desteklemediğini kontrol edin. ESXi hostunuza SSH ile bağlanın veya ESXi Shell ekranından şu komutu çalıştırın:

Kod 
Yığını:
esxcli storage core device list

Çıkan uzun liste içerisinde depolama birimlerinizin detaylarında "Is VAAI capable: true" yazıp yazmadığını kontrol edin. Eğer true ise storage'ınız bu özelliği destekliyor demektir.

2. Adım: ESXi Host Üzerinde VAAI Durumunu Kontrol Etme

Varsayılan olarak ESXi'da VAAI özellikleri açık olsa da bazen sistem genelinde kapatılmış olabilir. Hangi VAAI parametrelerinin aktif olduğunu görmek için şu komutu çalıştırın:

Kod 
Yığını:
esxcli system settings advanced list -o /DataMover/HardwareAcceleratedMove
esxcli system settings advanced list -o /DataMover/HardwareAcceleratedInit

Eğer dönen çıktıdaki Int Value değeri 1 ise aktif demektir, 0 ise kapalıdır.

3. Adım: VAAI Özelliklerini Manuel Olarak Aktif Etme (Komut Satırı)

Eğer yukarıdaki komutlarda değerler 0 çıktıysa ve VAAI kapalıysa, ESXCLI üzerinden şu komutlarla anında aktif edebilirsiniz.

• Hardware Accelerated Move (Klonlama/Taşıma hızlandırma) açma:

Kod 
Yığını:
esxcli system settings advanced set -i 1 -o /DataMover/HardwareAcceleratedMove

• Hardware Accelerated Init (Sıfırlama/Boş disk oluşturma hızlandırma) açma:

Kod 
Yığını:
esxcli system settings advanced set -i 1 -o /DataMover/HardwareAcceleratedInit

• ATS (Atomic Test and Set) Kilitleme optimizasyonunu açma:

Kod 
Yığını:
esxcli system settings advanced set -i 1 -o /VMFS3/HardwareAcceleratedLocking

4. Adım: vSphere Client (Web Arayüzü) Üzerinden Kontrol Komut satırı yerine görsel arayüzden kontrol etmek isterseniz de şu adımları uygulayın;

1. vSphere Client'a giriş yapın.
2. ESXi hostunuzu seçin ve Configure (Yapılandır) sekmesine gelin.
3. Sol menüden Storage > Storage Devices kısmına tıklayın.
4. İlgili datastore cihazını seçtiğinizde alt kısımda Hardware Acceleration durumunun Supported (Destekleniyor / Aktif) yazdığından emin olun.

VAAI aktif edildikten sonra sanal makine klonlama sürelerinin dakikalardan saniyelere düştüğünü özellikle yoğun I/O altındaki veritabanı sunucularında ESXi host CPU yükünün ciddi oranda azaldığını net bir şekilde görebilirsiniz. Destekleyen bir altyapınız varsa bu ayarın kapalı kalması büyük bir performans kaybıdır.

Tekrardan herkese iyi forumlar dilerim.

Herkese selamlar,

Geçen gün projelerin olduğu VDS'lerden birinde garip bir yavaşlık sezdim. CPU kullanımı sürekli %100'de geziniyor site yanıt vermiyor. SSH ile sunucuya baktığımda top ve htop ekranında adını bile daha önce duymadığım rastgele harflerden oluşan garip bir process CPU'yu sömürüyor.

Klasik bir cryptojacking vakasıyla karşı karşıya olduğumu o an anladım. Muhtemelen zayıf bir şifreden ya da güncel olmayan bir web uygulamasından içeri sızmışlar. Sunucuyu komple formatlamadan, bu izinsiz process'i nasıl yakaladığımı, kökünü kurutup diskten nasıl temizlediğimi bu sorunu yaşayanlar için adım adım buraya bırakıyorum.

Sunucuda bu tarz bir durumla karşılaşınca panik yapıp direkt sunucuya reset atmamak gerekir. Şöyle bir yol izleyebilirsiniz;

1. Adım: Hangi İşlemin CPU'yu Sömürdüğünü Bulmak (htop / top)

Öncelikle SSH ile sunucuya bağlanıp anlık olarak sistemi yoran process'i ve PID (Process ID) numarasını tespit ediyoruz:

Kod 
Yığını:
htop

(veya htop yoksa top komutu)

Listede en üstte CPU'yu %99 kullanan garip isimli (örneğin rastgele xmr-stak, kworker kılığına girmiş sahte servisler veya anlamsız dizinlerden çalışan) dosyanın PID numarasını bir kenara not edin (4821 gibi)

2. Adım: İşlemin Disk Üzerindeki Yerini Bulmak

İşlemi öylece sonlandırıp bırakmayın. Çünkü arkada çalışan bir cronjob veya servis onu tekrar aktif hale getirebilir. Önce zarar veren kısmın dosya sisteminde nereye saklandığını bulmamız lazım.

Şu komutla çalışan process'in kök dizinini ve çalıştırıldığı yolu öğrenebilirsiniz;

Kod 
Yığını:
pwdx 4821
# veya şu komutla tam dosya yolunu görün:
ls -l /proc/4821/exe

(Çıktıda size /tmp/... veya /var/tmp/... ya da /usr/bin/ altında garip bir dosya yolu verecektir.)

3. Adım: Süreci ve İlgili Ağ Bağlantılarını Kesin

Zarar veren kısmın dosya yolunu öğrendikten sonra artık süreci sonlandırabilirsiniz.

Kod 
Yığını:
kill -9 4821

4. Adım: Zararlı Kaynak Dosyasını ve Uzantılarını Silmek

Bulduğumuz dosya yoluna giderek zararlı script'i veya binary dosyayı ortadan kaldırıyoruz.

Kod 
Yığını:
rm -rf /tmp/zararli_dosya_adi

(Dikkat edin, /tmp veya /var/tmp dizinlerinde bu tarz gizli klasörler .hidden şeklinde de bulunabilir. ls -la /tmp yaparak gizli dosyaları mutlaka kontrol edin.)

5. Adım: En Önemli Kısım - Tekrar Tetiklenmesini Engellemek

Korsanlar genellikle bu tarz zararlıları sistem yeniden başladığında veya belli aralıklarla tekrar çalışması için şu noktalara saklarlar. Buraları mutlaka temizlemelisiniz:

• Crontab (Zamanlanmış Görevler) Kontrolü:

Kod 
Yığını:
crontab -l
# Kullanıcı crontab'lerini kontrol edin:
cat /etc/crontab
ls -la /etc/cron.d/

Eğer burada kendinizin eklemediği, şüpheli bir wget veya curl komutuyla dışarıdan dosya çekip çalıştıran satırlar varsa hemen temizleyin.

• Systemd Servis Kontrolü:

Kod 
Yığını:
systemctl list-units --type=service --state=running

Sistem servisleri arasına yerleşmiş garip isimli bir servis var mı diye göz atmayı unutmayın varsa systemctl disable --now servis_adi ile kapatıp ilgili service dosyasını (/etc/systemd/system/ altından) silin.

6. Adım: Şifreleri ve Yetkileri Sıkılaştırmak

Zararlı dosyayı temizledikten sonra kapıyı aralık bırakmamak için;

• SSH portunuzu varsayılan 22'den başka bir şeye taşıyın.
• Şifreli (Password) SSH girişini kapatıp sadece SSH Key (Anahtar) ile girişe geçin.
• Kullanıcı yetkilerini (sudo listesini) gözden geçirin.

Sunucuda CPU'nun %100'e fırlaması ve fanların çıldırması genelde bu tarz kriptocuların eseridir. Panik yapmadan pwdx ve ls -l /proc/.../exe ikilisiyle zararlının kaynağını bulup temizlemek sistemi kurtarmak için yeterlidir.

Herkese iyi forumlar.

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.