سجل إصدارات ONOXSOFT

ONOXSOFT 2026.8.48 — Panelde ayarladığınız şeyler artık gerçekten uygulanıyor

Bu sürümün tamamı tek bir kusur sınıfını kapatıyor: **panel bir şey gösteriyor,
sistem başka şey yapıyor.** Kullanıcı bir ayarı değiştiriyor, "kaydedildi"
mesajını alıyor, değer ekranda kalıcı görünüyor — ve hiçbir şey değişmiyor.

Bu sınıf hata üretmez, logda görünmez, kimse "bozuk" diye bildirmez. Sadece
olmaz. En sinsi tarafı da bu.

---

1. Güvenlik ayarları hiçbir şey yapmıyordu (SAHTE UYUM)

"Genel Sistem Ayarları → Güvenlik" grubundaki dört eşik `server_settings`'e
yazılıyor ve ekranda kalıcı görünüyordu — ama hiçbir kod onları okumuyordu.
Gerçek değerler üç ayrı yerde sabitti:

| Katman | Eskiden | Şimdi |
|---|---|---|
| `throttle:login` limiteri | 5 deneme / 15 dk sabit | ayardan |
| `LoginRequest` | 5 sabit | ayardan |
| `AccountLockout` | 10 deneme / 60 dk sabit | ayardan |
| Parola tabanı | `Password::min(8)` sabit | ayardan |

Admin "Maks. giriş = 3, Parola min = 14" kaydedip ekranda görüyor, sistem 5 ve
8'de kalıyordu. Bir denetimde "panelden sertleştirdik" savunması bu yüzden
sahteydi.

Clamp'ler tesadüf değil — bu sayfa admin'in kendi giriş kapısını ayarlıyor.
Kilit alt sınırı 5 dakika, çünkü altı korumayı bugünkünden zayıflatır
(5 deneme/1 dk = günde 7200 deneme; bugün 480). Oturum alt sınırı 5 dakika, çünkü
altı admin "Kaydet"e basana kadar oturumu düşürüp 419 döngüsü üretir.

Pencere neden `lockout_minutes` değil: `ThrottleRequests` her istekte koşulsuz
sayaç artırır — başarılı giriş de sayılır. O katman bir "başarısız deneme" sayacı
değil, istek sayacıdır. Pencereyi 24 saate açsaydık "Kilitleme = 24 sa" diyen
admin kendi kullanıcılarını günde 5 başarılı girişle sınırlardı. Kilit süresi
yalnız `AccountLockout`'ta yaşar; orası sadece başarısızlığı sayar ve başarıda
sayacı siler.

> Davranış değişimi: `AccountLockout` varsayılanı 10 deneme / 60 dk idi;
> yeni varsayılan 5 deneme / 15 dk. Kilit daha erken devreye girer, daha erken
> açılır.

---

2. Mail kuyruğu alarmı matematiksel olarak tetiklenemiyordu

Pano alarm servisine sabit `0` besliyordu; `mailQueue()` ise
`if ($count <= $warn) return []` yapıyor. `0 <= eşik` daima doğru olduğu için
eşiği 50'den 1'e çekmek bile hiçbir şey değiştirmiyordu. Postfix/Exim kuyruğu
tıkandığında panoda ve Telegram'da hiçbir uyarı çıkmıyordu.

Buradaki asıl incelik ayrımdı:

| Durum | Değer | Anlamı |
|---|---|---|
| Kuyruk tutmayan sürücü (none/relay) | `0` | gerçek ölçüm — kuyruk kavramı yok |
| Sürücü postfix/exim, binary yok | `null` | ölçülemedi |
| sysapi hatası | `null` | ölçülemedi |

`null`'da alarm kurulmaz ama "temiz" de denmez. Sıfır dönmek, kuyruk tıkalıyken
uyarıyı bastırırdı — yani düzeltmenin sebebi olan hatanın aynısını üretirdi.

Telegram yolu ayrıca bağlandı; bildirimi gönderen tek yer orası.

---

3. Kaynak hatası kayıtları hiç yazılmıyordu

`account_resource_faults` tablosunun tek yazıcısı `CgroupManager::recordFault()` ve
sıfır çağrılıydı. Eşiği gerçekten ölçen komut olayı doğrudan üretiyordu:
limit-aşımı e-postası gidiyor ama panelde karşılığı yok. Müşteri
"Kaynaklarım"da, admin hesap detayında ve "Hata Geçmişi"nde hep boş tablo
görüyordu; Prometheus metriği kalıcı 0'dı.

İki tuzak vardı: tablo ENUM'u `cpu_limit`/`pmem_limit`/`ep_limit` bekliyor, komut
`cpu`/`memory`/`processes` üretiyordu — ham yazsaydık düzeltme ekranı bu kez
hatayla boş bırakırdı. Ve komut 5 dakikada bir koştuğu için tekrar bastırma
olmadan günde ~288 satır ve 288 e-posta üretirdi. Aynı hesap+tür için saatte
tek kayıt.

---

4. Docker motor kartı geri geldi + firewall sahte alarmı susturuldu

`7beb6a8a` prod-senkron ailesinin son üyesi. `docker.install` /
`daemon.start` / `daemon.stop` / `status` rotaları ve controller `311a5da7`'de
eklenmişti; prod-senkron kartı ezdi ve o günden beri bu rotaları çağıran **tek
satır JS yoktu.** Container Hosting satılıyor ama Docker kurulu olmayan sunucuda
panelden kurulamıyordu — tek yol SSH'tı.

Karta üç emniyet kondu: canlı daemon bayat kurulum durumunu ezer (operatör SSH'tan
düzeltirse kart kilitlenmesin); kurulum takılırsa çıkış yolu verilir (kuyruk işçisi
çalışmıyorsa durum kendiliğinden çözülmez); ve **"hazır" artık kurulu değil
çalışıyor demek** — eskiden Docker kurulu ama servis durmuşken butonlar aktif
görünüyor, tıklayınca reddediliyordu.

Firewall: `onox:firewall-apply` normal durumda 6 saatte bir FAILURE basıyordu
(firewall özellikleri hiç kullanılmamışsa `inet onox` tablosu yoktur → dökülecek
state de yoktur). Bu gürültü, gerçek bir arıza çıktığında kimsenin bakmadığı bir
alarma dönüşüyordu.

Susturma koşullu: daha önce dump dökülmüşse ya da panelde nft'ye yansıması
gereken kayıt varsa, tablonun yokluğu koruma kaybıdır — panelde kural görünür,
sunucuda uygulanmaz. Koşulsuz `SUCCESS`'e çevirmek bu kaybı sonsuza dek gizlerdi.

---

5. Posta taşıma: Gmail / Outlook / Yandex

Gmail'den taşımaya çalışan kullanıcı şu ham metni görüyordu:

```
Bağlantı kurulamadı: Can not authenticate to IMAP server: [ALERT]
Application-specific password required: https://support.google.com/accou…
```

İlginç olan şu: `humanError()` tablosunda **"uygulama parolası ister" dalı zaten
vardı** ama Gmail'de hiç tetiklenmiyordu. Tablo `authentication fail` arıyordu,
Gmail ise `authenticate to IMAP server` diyor. Panel durumu "anlıyor"
görünüyordu; ayırt edici imza yanlış seçilmişti.

Üç katman:

• Sağlayıcıya özel yönergeler. Sıra önemli: IMAP'in kendisi kapalıysa parola

değiştirmek işe yaramaz, o dal en başta. Gmail, Microsoft 365 (temel kimlik
doğrulama kapatıldı), Yandex (IMAP varsayılan kapalı; **kurumsal 360'ta kullanıcı
adı tam e-posta adresi**).

• MX tabanlı tespit — kurumsal kutular için asıl düzeltme. `mail.firma.com`

kaydının çözülmesi hiçbir şey kanıtlamıyor; eski hosting'in A kaydı yıllarca
ayakta kalır. MX, postanın bugün nereye gittiğini söyler. Bu adım olmadan
Google Workspace / Yandex 360 kullanan müşteri yeni sağlayıcının parolasını
eski sunucuya gönderiyor ve hatayı "parola yanlış" sanıyordu.

• Ölü host düzeltildi — `imap.yandex.com.tr` artık yayımlanmıyor. Bu liste

DNS'te çözülüp çözülmediğine bakmadan dönüyordu; yanlış bir ad "uydurma host
önermeyiz" ilkesinin sessiz ihlaliydi.

Tanınmayan MX için öneri üretilmiyor — `mx1.eskihosting.com` gördük diye onu
IMAP hostu saymak, çözülmeyen host önermekle aynı hata olurdu.

---

6. Yedek profili ayarları uygulanmıyordu

Zincir üç yerde kopuyordu:

```
BackupController → BackupSchedule → RunBackupScheduleJob → RunAccountBackupJob → BackupService
↑ kapsam + hariç-tut düşüyor ↑ sıkıştırma düşüyor
```

`BackupService` `include_dbs`/`include_mail`/… seçeneklerini **zaten
destekliyordu** — zincirde onları dolduran kimse yoktu, hepsi `full` varsayılanına
düşüyordu. "Sadece Veritabanı" profili kuran admin rozeti görüyor, gerçekte her
gece her hesabın tam home'u + posta + DNS + SSL + FTP + cron tar'lanıyordu.

Bu, 2026.8.47'de düzeltilen 169 yedek çığının kök nedeniydi: kapsam
daraltılabilseydi 46 GB'lık hesap saatlerce gzip'lenmeyecekti.

Bilinmeyen kapsam değeri her şeyi yedekler: fazla yedek disk maliyetidir,
eksik yedek veri kaybıdır.

Hariç tutulan yollar çip olarak gösteriliyor ama `tar`'a hiç iletilmiyordu —
20 GB'lık `node_modules` her gece yeniden tar'lanıyordu.

Sıkıştırma bilerek yapılmadı — ve UI artık yalan söylemiyor

`onx-backup-restore` `home.tar.gz` adını ve `tar -xzf`i sabit kullanıyor.
Kodeği değiştirmek, farklı kodekle alınmış bir arşivin geri yüklenememesi
demek. Yedek geri yükleme son savunma hattıdır; kozmetik bir ayar için riske
atılmaz.

Seçenek devre dışı bırakıldı ve durum açıkça yazıldı. Betiğe eklenmiş atıl
`COMPRESSION` ayrıştırması da kaldırıldı — kullanılmayan kod bırakmak, bu sürümün
düzelttiği günahın aynısı olurdu.

---

7. E-posta şablonu override'ları kullanılmıyordu

Admin 21 şablonu TR/EN düzenleyip kaydediyordu; kayıt `email_templates` tablosuna
gidiyordu. Ama giden e-posta her zaman varsayılan Blade'di:
`TemplateRenderer` üretimde sıfır çağrılıydı.

Teşhisi neredeyse imkânsızdı: önizleme de Blade render ediyordu, yani ekranda
"değişikliğim uygulandı" görünüyordu. Şikâyet "e-posta gitmiyor" olarak da gelmez —
gider, yanlış içerikle.

Anahtar view adından türetiliyor (`emails.account.suspended` →
`account.suspended`), böylece view ile anahtar yapısal olarak ayrışamaz.
25 Mailable'ın tamamı bağlandı; test `new Content(view:)` doğrudan çağrısını
yasaklıyor.

Mevcut davranış birebir korunur: override yoksa aynı Blade view ile aynı
`Content` kurulur.

---

8. Marka footer HTML'i basılıyor (sanitize'li)

Alan 2026-05'ten beri kaydediliyor, `brand` prop'una konuyor ve formda geri
görünüyordu — ama hiçbir layout basmıyordu. (Kıyas: aynı formdaki `custom_css`
basılıyordu, yani taşıma zinciri sağlamdı.)

Basmaya başlamak güvenlik yüzeyi açar: alan `v-html` ile admin ve müşteri
panelinde, aynı origin'de render ediliyor. Formda `custom_css` ile yan yana
duruyor ama aynı risk değil — CSS kod çalıştırmaz, HTML çalıştırır.

Beyaz-liste temizleyici eklendi:

• Fail-closed — `BrandResolver::platform()` her istekte çalışıyor; kaçan tek

istisna admin + müşteri + giriş dahil tüm panelde 500 demek. Temizleyemezse ham
basmak yerine düz metne iner.

• Raw-text öğeleri içeriğiyle silinir, unwrap edilmez — libxml2'nin HTML4

ayrıştırıcısı ile tarayıcının HTML5'i tam da orada ayrışır (mXSS yüzeyi).

• Hem yazarken hem okurken çalışır: alan aylardır doğrulanmadan kaydediliyordu,

yazma kapısı geçmiş kayıtları güvenli yapmaz.

Yazma yolu yalnız admin'e açık (bayi bu alana erişemiyor).

---

9. WordPress filosunda pasif siteler ayrı grupta

Askıdaki hesabın ya da DNS'i düşmüş alan adının WP sitesi zaten erişilemez. Onu
ana risk listesinde "güncelleme bekliyor / savunmasız" diye göstermek iki zarar
veriyordu: admin düzeltemeyeceği satırlarla uğraşıyor, ve gerçekten çalışan
savunmasız siteler bu gürültünün altında kayboluyordu.

Pasif siteler listeden atılmıyor — silinmiş gibi görünmeleri de yanlış olurdu.
Ayrı grupta, altta ve sebebiyle duruyorlar.

`dns_health_status` yalnız `down` iken pasif sayılır; **ölçülmemiş durum siteyi
pasif grubuna atmaz.**

---

10. MX senkron vaadi kaldırıldı

Panel iki yerde "DNS MX kayıtları senkronize edilir" diyordu ama DNS'e hiç
dokunmuyor: `applyAllForDomain()` 2026-05-28'den beri **hiçbir yerden
çağrılmıyor.** Müşteri "uzak" moda geçip postasını taşıdığında MX hâlâ
`mail.<alan>` kalıyor ve posta bu sunucuya düşmeye devam ediyordu.

Otomatik yazım bilerek yapılmadı: mevcut kod bağlansaydı kullanıcının girdiği
`primary_mx`/`backup_mx` alanlarını hiç okumuyor ve `remote` dalında alan adını
sıfır MX ile bırakabiliyordu — posta kaybı. Panel şimdilik doğruyu söylüyor.

---

Doğrulama

Tam süit A/B, kararlı `dosya:satır` anahtarlarıyla:

| | Kırık konum | Geçen |
|---|---|---|
| 2026.8.47 | 173 | 1343 |
| 2026.8.48 | 173 | 1387 |

Sıfır regresyon. Birim testleri 537 → 581. Değiştirilen her Vue dosyası
`@vue/compiler-sfc` ile gönderilmeden önce derlendi (bir dengesiz etiket bu
sayede yakalandı).

---

Bu sürüme GİRMEYENLER (ve nedeni)

| Madde | Neden ertelendi |
|---|---|
| Yedek sıkıştırma (zstd/xz) | `onx-backup-restore` gzip'e sabit; önce restore kodek-duyarlı yapılıp gerçek geri yükleme testi koşulmalı |
| HSTS anahtarı | Arka uç da ölü: `toggleHsts` ayarı `autossl_settings`'e yazıyor, onu da kimse okumuyor. UI eklemek hiçbir şey yapmayan bir düğme daha koymak olurdu |
| Vanity nameserver | Risk analizi 8 kırılma buldu, 3'ü canlı etkili — en ağırı kaydetme isteği içinde senkron DNS sorgusu (bayi hiçbir ayarını kaydedemez hâle gelirdi). Kuyruk işi + doğrulama + zamanlama gerektiriyor |
| GFS saklama (keep_*) | Profil-bazlı retention ayrı bir ürün kararı |
| Bayi toplu işlem | Her toplu uç sahiplik filtresinden geçmeli; admin kodunu kopyalamak çapraz-kiracı açığı olurdu |

ONOXSOFT 2026.8.47 — Canlı kullanımda bildirilen hatalar

Bu sürüm gerçek kullanım sırasında bildirilen yedi kusuru kapatıyor. Üçü **aktif
zarar** veriyordu: her gece onaylanmamış WordPress güncellemesi koşuyor, bir
sunucuda yedek sistemi diski dolduruyor, yüklenen her marka görseli 404 dönüyordu.

Ortak desen yine aynı: panel bir şey gösteriyor, sistem başka şey yapıyor.

---

1. Postfix "Mail Kuyruğu" sekmesi beyaz ekran veriyordu

`e11b9b8c` ("uydurma veriyi durdur") kontrolcüdeki 10 satırlık sahte kuyruk
dizisini gerçek sysapi çağrısıyla değiştirdi — ama sahte dizinin Vue ile
paylaştığı veri sözleşmesini taşımadı:

| | Sahte veri (eski) | `onx-postqueue-status` (gerçek) |
|---|---|---|
| boyut | `size_kb` | `size` (bayt) |
| zaman | `arrival_time` | `arrival` |
| alıcı | `recipients` (dizi) | `recipient` (tekil string) |

Vue hâlâ `entry.recipients[0]` diyordu → `undefined` dereference → render
`TypeError` → tüm ağaç devriliyor → beyaz ekran. Sekme `v-if` içinde olduğu
için sayfa ilk açılışta sorunsuz geliyor, yalnız "Mail Kuyruğu"na tıklayınca
patlıyordu. Kuyruk boşken `v-for` hiç satır üretmediğinden hata aralıklı
görünüyordu.

Kontrolcüde normalizasyon eklendi (aynı dönüşüm `MailQueueService::fetchPostfix`'te
zaten vardı — `/admin/mail/queue` bu yüzden çalışıyordu) ve Vue savunmacı
yapıldı: tek bir eksik anahtar bir admin sayfasını komple devirmemeli.

Yan bulgu: `deferred`/`hold` değerleri payload'ın kökünden okunuyordu,
oysa `totals` altındalar → Genel Bakış kutuları her zaman boştu. Veri zaten
mevcuttu, yalnız yanlış yoldan okunuyordu.

---

2. WordPress "Otomatik Güncelleme" anahtarı hiçbir şey yapmıyordu (AKTİF ZARAR)

Toggle değeri `config_overrides['auto_update']` JSON anahtarına yazıyordu; gece
04:00'te koşan motor (`onox:wp-auto-update` → `WpAutoUpdateService::flaggedQuery`)
ise yalnız `auto_update_core` / `_plugins` / `_themes` kolonlarını sorguluyor.
Kolonlara yazan tek bir kod yolu hiç olmadı → tüm satırlar migration
varsayılanında (`'minor'`) kaldı ve süzgeç tüm aktif WP sitelerini eşledi.

Zarar iki yönlüydü:

• Toggle'ı kapatan müşterinin sitesinde her gece `wp core update --minor`

koşmaya devam etti. Servisin kendi notu: ROLLBACK YOK — bozulan siteye
yalnız uyarı gidiyor, elle yedekten dönülüyor.

• Toggle'ı açan müşterinin eklenti/temaları hiç güncellenmedi → beklenen

güvenlik yamaları uygulanmadı.

Her iki toggle da (admin + müşteri) artık kolonlara yazıyor; rozet ve motor
aynı koşuldan türüyor (`InstalledApp::autoUpdateEnabled()`).

Veri geçişi: tek sözleşme, panelin bugüne kadar gösterdiği durumdur.
Dokunulmamış `'minor'` bir müşteri tercihi değil, migration artığıdır → `'off'`.
Bilinmeyen durum yıkıcı olmayan tarafa düşer: onay verilmemiş bir güncelleme
artık sessizce koşmaz. `down()` satırlara dokunmaz — fix sonrası verilen
kararı silmek ve rollback'te tüm sitelerde gece güncellemesini yeniden açmak
olurdu.

---

3. Yedek çığı: bir hesap diski dolduruyordu (CANLI OLAY)

169 sunucusunda 46 GB'lık bir hesabın gzip'i 1 saati aşıyordu. PHP tarafı 3600
saniyede vazgeçiyor, ama `tar` çalışmaya devam ediyordu. Bir sonraki saatlik
tetik yeni bir tar başlatıyordu.

Olay anındaki tablo: aynı anda 3 yetim tar (5s21d / 4s21d / 3s20d),
`/tmp`'de 30 GB yarım arşiv, disk %90. Hiçbiri "hata" vermiyordu — her tur
yalnızca timeout'a düşüyor ve sessizce birikiyordu.

Üç katman eklendi:

| Katman | Neden |
|---|---|
| Hesap başına `flock` | Aynı hesap için ikinci yedek başlamaz. "Atlandı" açıkça raporlanır — atlamak bir başarı değildir |
| `TERM/INT/HUP` tuzağı | `trap ... ERR` yalnız komut hatasında çalışır; PHP timeout'ta SIGTERM gönderdiğinde tetiklenmezdi. Süreç grubu öldürülür, çünkü gzip tar'ın çocuğudur |
| Bayat artık süpürme | Ölü PID'li eski iş dizinleri temizlenir (her biri GB'larca yer kaplıyordu) |

Canlıdaki artıklar ayrıca elle temizlendi: disk %90 → %75. Tamamlanmış
yedeklere (`/var/backups`, 15 GB) dokunulmadı.

---

4. Marka görselleri yüklendikten sonra 404 dönüyordu

Yükleme dosyayı `public` diskine (`storage/app/public`) yazıp DB'ye
`/storage/branding/xxx.png` URL'i kaydediyor. Bu URL yalnız doküman kökünde
`public/storage` bağlantısı varsa servis edilir.

Bağlantıyı kuran tek yerler ansible role'ü ve docker entrypoint'iydi. Üç canlı
sunucunun kullandığı bare-metal `install.sh` ve `onx-panel-self-update`
`storage:link`'i hiç çalıştırmıyordu; `/public/storage` `.gitignore`'da
olduğu için sürüm tarball'ı da taşımıyor.

`storage:link` tek başına yetmezdi: üç sunucuda da `public/storage` bir
symlink değil, Ocak 2025'ten kalma boş gerçek dizin. Laravel'in komutu
hedef varken "zaten mevcut" deyip çıkar. 169'da `storage/app/public/branding`
altında 5 görsel duruyordu (biri o gün yüklenmiş) — hiçbiri servis
edilmiyordu.

Düzeltme boş dizini kaldırıp bağlantıyı kurar; dolu ise dokunmaz (içeriğini
bilmediğimiz bir dizini silmek veri kaybı riskidir). Ayrıca yükleme uçları
`PublicStorageLink::ensure()` kapısından geçer: bağlantı kurulamıyorsa yükleme
başarılı sayılmaz — 404 servis edecek bir URL'i DB'ye mühürlemek, kullanıcıya
olmayan bir şeyi olmuş gibi göstermektir.

---

5. Antivirüs imza beslemesi "pasif" görünüyordu

Durum betiği iki ayrı yalan söylüyordu:

• `sigs` alanı dosya sayıyordu, imza değil. Canlıda 8 SaneSecurity dosyası

"8 imza" diye görünüyordu — gerçek sayı 40.804 (LMD için 2 → 47.759).

• `updated_at` sabit `null` idi, hiç ölçülmüyordu. Panel null'ı "hiç

güncellenmedi" diye basıyor ve besleme pasif görünüyordu; oysa dosyaların
mtime'ı zaten oradaydı.

Artık `.cvd/.cld` için `sigtool`, düz metin imza dosyaları için satır sayımı
kullanılıyor; `updated_at` gerçek mtime. Dosya sayısı ayrıca raporlanıyor ki
panel "imza okunamadı" ile "besleme yok"u ayırt edebilsin.

> Resmî ClamAV veritabanının kendisi sağlıklıydı (`daily.cld` günlük güncelleniyor
> — freshclam panelden bağımsız çalışır). Beslemelerin bayat kalmasının sebebi
> panelin antivirüs ana anahtarının kapalı olmasıydı; bu bir ayar, kusur değil.

---

6. Bayi listesinde "Son giriş" hep boştu

Ekran `$u->last_login_at`'ı okuyup biçimlendiriyordu ve boşsa "Hiç giriş yapmadı"
basıyordu. Ama `users.last_login_at` kolonu hiç var olmadı → okuma her zaman
`null`. Bayi her gün giriş yapsa bile ekran aynı şeyi diyordu.

Kolon (+ `last_login_ip`) ve `RecordUserLogin` dinleyicisi eklendi. Controller'a
kod koymak yetmezdi: bu panelde giriş tek yoldan olmuyor — parola, passkey
(WebAuthn), WHMCS/WiseCP SSO redeem, impersonation ve "remember me". Hepsi
`Illuminate\Auth\Events\Login` tetikler; tek dinleyici hepsini kapsar. Dinleyici
giriş akışını asla kırmaz (kolon yoksa veya DB yazamazsa sessizce geçer).

---

7. Aynı WordPress sitesi listede iki kez görünüyordu ("vlatest" ve "7.0.2")

İki ayrı kök neden:

• `'latest'` bir sürüm değil, bir istektir. `AppVersionResolver` katalog

değerini çözemeyince ham `'latest'` dizesi kolona kalıcı yazılıyordu.
Ekranda "v" önekiyle birleşip "vlatest" görünüyordu.

• Keşif dedup'ı `install_path`'i ham eşitlikle eşliyordu. Panel kurulumu ve

disk keşfi aynı dizini farklı yazabiliyor (sondaki `/`) → farklı sanıp aynı
site için ikinci kayıt üretiyordu.

Artık `'latest'` yerine `'unknown'` yazılır (gerçek sürüm WP-CLI/keşif ile
okunur), yol normalize edilerek eşlenir, ve ekran "v" önekini yalnız gerçek sürüm
numarasına ekler.

---

Doğrulama

Tam süit A/B, kararlı `dosya:satır` anahtarlarıyla:

| | Kırık konum | Geçen |
|---|---|---|
| 2026.8.46 | 173 | 1334 |
| 2026.8.47 | 173 | 1343 |

Sıfır regresyon. Birim testleri 528 → 537.

> Kalan 173 kırık konum bu sürümden önce de kırıktı ve ayrı bir iş kalemidir.

---

Bu sürüme GİRMEYENLER (8.48'e)

Teşhisleri tamamlandı, uygulaması sürüyor: posta taşıma sağlayıcı ön ayarları
(Gmail/Outlook/Yandex), bayi panelinde toplu işlem, WP filo ekranında DNS-pasif
grubu, admin güvenlik ayarlarının gerçekten uygulanması, mail kuyruğu alarmı,
kaynak hatası kayıtları, Docker motor kartı, yedek profili ayarları
(kapsam/saklama/hariç-tut/sıkıştırma), e-posta şablonu override'ları, MX senkronu.

ONOXSOFT 2026.8.46 — Ölü bağlantılar: zamanlanmamış işler, budanmayan tablo, ulaşılamayan sayfalar

2026.8.45'in devamı. Aynı kusur sınıfı — kod var, çağıran yok — ama bu sefer
kaynağı iki farklı yer: (a) hiç yazılmamış zamanlamalar, (b) `7beb6a8a`
prod-senkronunun sildiği bağlantılar.

Bu sürümün en önemli dersi şu: **düzeltmelerin üçü "tek satır ekle" gibi
görünüyordu, ikisi değildi.** Tek satırı eklemek olmayan bir özelliği açar ve
yerine gerçek bir açık koyardı.

---

1. `7beb6a8a` bir AİLE regresyon bırakmış (2026.8.45 sadece bir üyesini düzeltti)

`/opt` bir git deposu değil; "prod tam senkronu" commit'i üretim ağacını depoya
geri yazdı ve yerelde çalışan bağlantıları sessizce geri aldı. Silinen kodun
kendisi değil, koda giden tek satırdı.

| Üye | Durum |
|---|---|
| Operasyon AI motoru HTTP yüzeyi | 2026.8.45'te geri geldi |
| `Event::listen(DomainAdded, IssueSslOnDomainAdded)` | bu sürümde |
| `Schedule::command('onox:operations:sweep')` | bu sürümde |

En sinsi tarafı: açıklama yorumları yerinde kaldı. Kodu okuyan biri

```
// v89 — Basit, listener-driven SSL kur (acme.sh primary / certbot fallback).
// AutoSslOnDomainAdded ile PARALEL çalışır ...
// Suspended hesaplarda bile çalışır (user report: "hesap askıdada olsa ssl'ini kurmadı").
```

yorumunu görüp bağlı sanıyordu. Altındaki `Event::listen` satırı yoktu. Ne hata,
ne log, ne test kırılması.

İki SSL dinleyicisi kopya değil tamamlayıcı: kayıtlı olan
(`AutoSslOnDomainAdded`) `autossl_settings.enabled != 1` ise tamamen atlıyor;
eksik olan tam da o durumda ve askıdaki hesaplarda devreye giriyordu. Yani
"AutoSSL zaten kayıtlı" demek yetmiyor.

`tests/Unit/System/ProdSyncRegressionGuardTest.php` üçünü birden mühürler, ayrıca
"yorum var, kaydı yok" desenini ayrıca test eder.

---

2. Telegram butonları — düzeltmenin kendisi bir güvenlik kapısı gerektirdi

`onoxsoft:telegram-poll` hiç zamanlanmamıştı. Uyarı kartlarındaki butonları
tüketen tek mekanizma bu (webhook yolu yok — `setWebhook` depoda hiç
geçmiyor). Sonuç: admin butona basıyor, Telegram spinner'ı dönüyor,
`answerCallbackQuery` hiç çağrılmıyordu.

Ama zamanlamayı tek başına eklemek güvenli değildi. Poller açıldığı andan
itibaren orası canlı bir komuta kanalıdır:

| Açık | Neden |
|---|---|
| Yetkisiz yıkıcı aksiyon | `authorized()`, `telegram_admin_user_ids` boşsa sohbet kimliğine düşüyor (`chatId === $tg->chatId()`). Hedef bir grup ise gruba eklenen herkes `service_restart` tetikleyebilirdi. |
| Yanlış sunucuda kesinti | Aynı bot token'ı birden fazla panelde tanımlıysa `getUpdates` akışını node'lar paylaşır, callback rastgele birine düşer. `callback_data` sunucu kimliği taşımaz, uyarı anahtarları geneldir (`service:MariaDB`) → anahtar eşleşmesi kanıt değil. "httpd yeniden başlat" başka sunucuda çalışabilirdi. |

İki kapı eklendi: yıkıcı aksiyon için beyaz liste zorunluluğu, ve `ownsCard()` —
kartı gönderen node'un kendi `dashboard_alert_states` satırına yazdığı
`telegram_message_id` ile sahiplik doğrulaması. `ack`/`iptal` kasıtlı olarak kapı
dışında: yalnız yerel state'e dokunurlar.

Zamanlama biçimi de mühürlendi: `runInBackground` (tur ~55 sn, ön planda tick'i
bloklardı), `withoutOverlapping(3)` (parametresiz hâli 1440 dk — tek bir OOM
butonları 24 saat öldürürdü), `onOneServer`, `when(isConfigured)`.

---

3. `whmcs_webhook_log` hiç budanmıyordu — ve budama kendisi risk taşıyordu

`retention.whmcs_webhook_log_days => 180` config'te **tanımlıydı ama okuyanı
yoktu. Tablo her billing webhook'unda (sipariş/askı/iptal + başarısız HMAC
denemeleri**) büyüyor, hiç silinmiyordu. `request_body`/`response_body` müşteri
adı, e-posta ve alan adı taşır — yani "180 gün" diye yapılandırılmış ama fiilen
sonsuz saklanan kişisel veri.

Kritik incelik: bu tablo aynı zamanda idempotency deposudur
(`idempotency_key` UNIQUE; `claimIdempotency()` tamamlanmış claim'i buradan
okur). Budama penceresi idempotency TTL'inden kısa olursa tamamlanmış bir claim
silinir, WHMCS aynı anahtarla retry ettiğinde kayıt bulunamaz ve sipariş
yeniden provizyonlanır → çift hesap. Pencere, ayarı kim düşürürse düşürsün
`TTL + 1 gün`e kelepçelendi.

Silme partili: `created_at` üzerinde indeks yok (migration yalnız
`endpoint` / `outcome` / `[hmac_verified,outcome]` / `processed_at` indeksliyor).
Aylardır budanmamış bir tabloda tek `DELETE` uzun kilit tutar ve tam o sırada
gelen billing webhook'ları 500 yer — yani "temizlik" işi sipariş kaybettirir.

---

4. Ulaşılamayan iki admin sayfası

Rota + controller + Vue hazır, menü girdisi yoktu — pratikte sayfa yoktur.

• Container Şablonları: admin'in katalogu yönetebildiği tek ekran. Girdi

olmadan yeni şablon eklenemiyor, riskli bir imaj pasife alınamıyordu; katalog
seed'lendiği gibi donuyordu.

• Mobil & Web Push: VAPID anahtarının panelden üretilebildiği tek yer. O

üretilmeden `.env` boş kalıyor ve hiç kimseye push gitmiyordu — abonelik,
job, cihaz modeli dahil tüm altyapı çalışır durumda ama beslenmiyordu.

Bilerek yapılmayan: Snapshot İçe Aktarma butonu

Denetim bunu da "eksik link" olarak işaretledi; eklenmedi. `87df13b9`'daki
kaldırma doğruydu. Geri eklemek üç somut zarar üretirdi:

1. `admin.snapshots.import.` kapısız, `admin.migration.` ise
`feature:cpanel_migration` ile kapılı → ödenmemiş özelliğe arka kapı.
2. `admin.migration.upload` `throttle:uploads` taşıyor, snapshot import
taşımıyor → rate-limit'siz 5 GB yükleme yüzeyi.
3. `importSnapshot()` istek-içi `sysapi(timeoutSeconds: 1800)` çağırıyor; gerçek
bir 5 GB arşivde FPM timeout'u bunu öldürür → DB'de kalıcı `importing` satırı
+ diskte temizlenmeyen 5 GB dosya.

Aynı offline arşiv yükleme akışı Migration sayfasında **kuyruk tabanlı ve
throttle'lı** olarak zaten çalışıyor.

---

Doğrulama

Tam süit A/B — kararlı `dosya:satır` anahtarlarıyla:

| | Kırık konum | Geçen |
|---|---|---|
| 2026.8.44 | 183 | 1289 |
| 2026.8.45 | 173 | 1319 |
| 2026.8.46 | 173 | 1334 |

Sıfır regresyon. Birim testleri 520 → 528.

> Not: Pest'in kısalttığı test adlarıyla (`FAILED … > helpe…`) karşılaştırma
> sahte alarm verir — kısaltma noktası koşumlar arasında kayar. Karşılaştırma
> `dosya:satır` anahtarı üzerinden yapılmalı.

---

Ayrıca: self-update extract dizin sahipliği (2026.8.45 kurulumunda yakalandı)

`tar --exclude='bootstrap/cache/*'` dizinin içeriğini eler, **dizin
girdisinin kendisini elemez.** Tarball o girdiyi `root/root` taşıdığı için tar,
canlı dizinin sahipliğini `apache:apache` → `root:root` yapıyordu; grup artık
root olduğundan Laravel her boot'ta *"bootstrap/cache must be present and
writable"* ile ölüyordu.

Pencere ~10 saniye ve her güncellemede tekrarlıyordu. 2026.8.45 kurulumunda
169 sunucusunda o pencerede tetiklenen beş zamanlanmış turbo işi sessizce düştü.

Desenler `storage`, `bootstrap/cache`, `public/build` olarak düzeltildi
(yıldızsız; GNU tar'da bir dizini elemek altındaki her şeyi de eler). Gerçek
tarball üzerinde ölçüldü: yeni desen tam olarak üç fazla üye eliyor — o üç
dizin girdisi, başka hiçbir şey.

> Bu düzeltme ancak bir sonraki güncellemeden itibaren etkilidir: extract'i
> çalıştıran, o an kurulu olan eski betiktir.

ONOXSOFT 2026.8.45 — Ölü özellikler: yazılan ama hiç okunmayan kod

Bu sürümün dört maddesi de aynı sınıftan: kod var, çağıran yok. Hiçbiri
hata üretmiyordu — hata üretecek bir şey çalışmıyordu ki. Bu yüzden hiçbiri
loglarda görünmüyordu ve hiçbiri "bozuk" diye bildirilmemişti; sadece
olmuyorlardı.

---

1. Bayi alt-paket limitleri hiç okunmuyordu (KOTA / GELİR)

`reseller_sub_packages.limits` 2026-05'ten beri yazılıyordu. Bayi kendi
ürününü tanımlıyor, `SubPackageManager::validateLimits()` her boyutu üst pakete
karşı titizlikle doğruluyor (üst paketi aşamaz, bayi havuzunu aşamaz, liste
tabanlı limitlerde alt küme olmalı), kayıt JSON olarak diske gidiyordu.

O limitleri okuyan tek bir satır kod yoktu. `ResellerSubPackage::limit()`
metodunun çağrıldığı yer sayısı sıfırdı.

Hesap açılırken alt-paketten yalnızca `parent_package_id` türetiliyordu; hesap
üst paketi alıyordu:

| Bayi ne satıyor | Müşteri ne alıyor | Bayi havuzundan ne düşüyor |
|---|---|---|
| Ekonomi — 5 GB | 100 GB (üst paket) | 100 GB |
| Ekonomi — 1 alan adı | 25 alan adı | 25 |
| Ekonomi — 2 veritabanı | 50 veritabanı | 50 |

Yani alt-paket bir isim ve fiyat etiketinden ibaretti. Zararı iki yönlüydü:
müşteri ödemediği kaynağı alıyor, bayi ise satmadığı kaynağı havuzundan
kaybediyordu — havuzu gerçekte dolmadan "doluyor" ve satış yapamaz hale
geliyordu.

Ne yapıldı

• `accounts.reseller_sub_package_id` sütunu (FK, `nullOnDelete` — alt-paket

silinirse hesap paketin limitlerine döner, silinmez ve limitsiz kalmaz).

• `ResellerSubPackage::effectiveLimit()` — limiti okuma anında üst pakete

kırpar. Doğrulama yazma anındadır; admin alt-paket oluşturulduktan sonra üst
paketi daraltabilir ve kayıt sessizce üst paketi aşan bir değer taşımaya
başlar. Okuma yolunda da kırpmak bu kaymayı zararsız kılar. Üst paket sınırlı
+ alt-paket sınırsız ise üst paket kazanır (bayi kendisine verilmemiş bir
sınırsızlığı dağıtamaz).

• Limit çözüm sırası tek: hesap override → alt-paket → paket → sınırsız.

`Account::effective*()` ailesinin tamamı ve alan adı sayısının tek
choke-point'i (`DomainProvisioner::assertCanAddDomain`) bu sıradan geçiyor.

• Havuz muhasebesinin iki ucu da alt-paketi görüyor: tahsis kontrolü

(`assertCanAllocate`) ve mevcut toplam (`currentAllocation`). Birini düzeltip
diğerini bırakmak iki sayının birbirini tutmaması demekti.

• Bayi hesap-açma ve paket-değiştirme formlarına alt-paket seçici; disk kotası

ekranda da alt-paketten türetiliyor (sunucudaki sıranın aynısı).

• Yetki kapısı: `exists:reseller_sub_packages,id` yalnız satırın var

olduğunu söyler — sahibi başka bir bayi olabilir. Sahiplik + üst paket
eşleşmesi + aktiflik zorunlu. API yolunda sahiplik hesabın sahibiyle
eşlenir, jetonu taşıyanla değil (admin başka bir bayi adına hesap açabiliyor).

Yan bulgu — aynı ezme kusurunun görüntü tarafı: `availablePackages()` hâlâ
`if (alt-paket parent'ları) … elseif (allowed_package_ids)` yapısındaydı. Kapı
(`assertPackageInPool`) 2026.7.16'da kesişime çevrildiği için bu artık güvenlik
değil tutarsızlık üretiyordu: bayi havuzunda olmayan paketi açılır listede
görüyor, seçiyor ve 403 yiyordu. Liste de kesişime çevrildi.

---

2. `POST /api/v1/accounts` hesabı hiç provision etmiyordu

Uç, `Account` satırını kaydedip 201 Created dönüyordu. `ProvisionAccountJob`
dispatch edilmiyordu.

Sonuç hayalet kayıt: Linux kullanıcısı yok, home dizini yok, vhost yok, site
404 — ama `LicenseSeatGuard` koltuğu sayıyor ve `ResellerAllocation` havuzdan
kotayı düşüyordu. Hiçbir hata da loglanmıyordu, çünkü hata yoktu: iş hiç
başlamamıştı.

Hesap oluşturmanın diğer iki yolu (WHMCS webhook, bayi paneli) bu işi zaten
kuyruğa atıyordu; bu uç sessizce paritesizdi. Yanıt artık
`"provisioning": "queued"` da taşıyor.

---

3. Operasyon Merkezi AI Motoru panelden erişilemiyordu

`7beb6a8a` commit'i Container/Observability sayfalarını eklerken AI motorunun
HTTP yüzeyini de sildi: `AdminOperationsController`, `routes/web.php`
bloğu, sidebar girdisi.

Arka uç olduğu gibi kaldı — dört ajan (Analist / Optimizer / RiskCritic /
Judge), eylem kataloğu ve dört handler, `ApplyPipeline` (snapshot → uygula →
doğrula → gerekirse otomatik geri al), iki iş, üç konsol komutu, üç
migration, iki Vue sayfası.

Sinsi olan şu: özellik pakete giriyor, migration'ları koşuyor, tablolar
oluşuyor, konsol komutları çalışıyordu. Panelden erişilecek tek bir yol yoktu ve
hiçbir hata üretmiyordu.

Rotalar, kontrolcü ve menü girdisi geri getirildi (`feature:ops_ai_engine`).
Ayrıca `OperationsServiceProvider` `bootstrap/providers.php`'de **kayıtlı
değildi** → dört ajan her biri ayrı bir `AiManager` çözüyordu (testte
`register('fake')` ikinci ajana ulaşmıyor, üretimde sağlayıcı dört kez
kuruluyordu). Kaydedildi.

Depodaki üç Operasyon test sınıfı bu yüzden kırmızıydı; bu sürümle yeşile döndü.

---

4. `CHAR_LENGTH` — güvenlik kapısı MySQL dışında duvara dönüyordu

2026.8.45 hazırlığında eklenen `DomainNamespaceGuard` (bir kiracının başka
kiracının adının altına yerleşmesini engelleyen kapı) en yakın üst alan adını
`orderByRaw('CHAR_LENGTH(name) DESC')` ile seçiyordu. `CHAR_LENGTH`
MySQL/MariaDB'ye özgüdür; SQLite'ta `no such function` ile patlıyor, yani kapı
sqlite kullanan her kurulumda alan adı eklemeyi tamamen kırıyordu.

Aday sayısı alan adının etiket sayısı kadardır (tipik 2–4), bu yüzden sıralama
sürücüden bağımsız olsun diye PHP tarafına alındı.

---

Doğrulama

Tam süit A/B koşuldu (aynı harness, yalnız bu sürümün dosyaları değişti):

| | Kırık | Geçen |
|---|---|---|
| Öncesi (2026.8.44) | 248 | 1289 |
| Sonrası (2026.8.45) | 218 | 1319 |

Sıfır regresyon. Onarılan üç sınıf (`AdminOperationsControllerTest`,
`OperationsEngineTest`, `OperationsDiagnoseCommandTest`) ve
`AccountModelTest` — hepsi depoda zaten vardı ve eksik bağlantı yüzünden
kırmızıydı.

Yeni sözleşme testleri: `tests/Unit/Reseller/SubPackageLimitContractTest.php`,
`tests/Unit/Operations/OperationsAiEngineWiringTest.php`,
`tests/Unit/Api/V1ApiContractTest.php`.

> Kalan 218 kırık test bu sürümden önce de kırıktı ve ayrı bir iş kalemidir;
> bu sürüm onlara dokunmadı.

ONOXSOFT 2026.8.44 — Log dizini sıkılaştırması güncellemenin SON işi

2026.8.43 üçüncü yazıcıyı kapattı ama dizin her güncellemede yine `0755`e
dönüyordu. Kök neden sıra: iyileştirme adımı güncellemenin başında koşuyor,
vhost yeniden yazımı ise sonra — ve o yol dizini tekrar açıyordu.

Canlı ölçüm: 8.43 kurulumundan sonra mod `755` (ctime tam güncellemenin bitiş
anı). Ardından 4 dakika izlendi, mod değişmedi → periyodik bir yazıcı yok;
açan şey güncellemenin kendi adımlarıydı ve sonrasında kimse kapatmıyordu.

Sıkılaştırma artık güncellemenin son işi (ilerleme %100 bildiriminden hemen
önce). Hangi adım açmış olursa olsun kapı en sonda kapanır. Sözleşme testi
sırayı da doğruluyor.

ONOXSOFT 2026.8.43 — Paylaşımlı log dizinini yeniden açan üçüncü yazıcı

2026.8.42'de `onx-vhost-add-ols` ve `onx-vhost-add-nginx` `0755` → `0750`
çevrilmişti. Ama üçüncü bir yazıcı kaçtı: `onx-ols-vhosts-unified-rewrite`
yolu bir değişken üzerinden yazıyor (`chmod 755 "${LOG_DIR}"`), bu yüzden
literal yol araması onu bulamadı.

Canlı sonuç: bu betiğin düzenli koştuğu sunucuda (son 45 dakikada 21 vhost
yeniden yazılmış) dizin her seferinde tekrar 0755'e açılıyordu. Diğer iki
sunucuda kapalı kalmıştı — orada bu yol o sıklıkta çalışmıyor. Yani düzeltme
iki sunucuda tuttu, birinde sessizce geri alındı.

Dizin tüm müşterilerin erişim loglarını bir arada tutuyor: ziyaretçi IP'si,
istenen URL, referrer — KVKK kapsamında kişisel veri.

Sözleşme testi de güçlendirildi

Eski test sabit bir dosya listesine bakıyordu; üçüncü yazıcıyı tam da bu
yüzden kaçırdı. Artık dizinden bahseden her sysapi betiğini tarıyor ve yol
bir değişkene alınmışsa değişken üzerinden verilen modu da yakalıyor.

Ders: aynı kaynağı yazan tüm yolları ararken değişken kullananları da tara;
literal arama tek başına yeterli değil.

ONOXSOFT 2026.8.42 — Firewall boot koruması, BoxTrapper karantinası, kaynak grafiği tarihleri

Üç alan izole çalışma ağaçlarında paralel geliştirildi ve her biri ayrı bir
inceleyici tarafından karşı-denetimden geçirildi.

1. Firewall boot-restore unit'ini hiçbir şey oluşturmuyordu

`onox-firewall-restore.service` boot'ta `nft -f` ile kuralları geri yükler —
ama bu unit'i üreten tek satır yoktu; adı yalnız yorumlarda geçiyordu. Bir
sunucuda elle oluşturulmuş (o yüzden çalışıyor), `install.sh` ile kurulanda
yok ve `nftables.service` devre dışı:

```
systemctl cat onox-firewall-restore.service → No files found
/etc/nftables/onox-restore.nft → VAR (cron yazıyor)
nft list tables → table inet onox (kurulu)
```

Yani dökümü üretiyoruz ama boot'ta yükleyecek hiçbir şey yok → **reboot'ta tüm
engel kuralları sessizce kalkar** (IP, ülke, bağlantı limiti, tehdit listesi).

Üstüne: onox tablosu yokken script `ok:true` dönüyordu ve panel "✓ döküm
güncellendi" basıyordu — koruma sıfırken yeşil rapor.

Artık unit idempotent kuruluyor (aynıysa hiçbir şey yazılmaz, `--now` yok →
canlı kurallara dokunulmaz), çağrı "tablo yok" erken çıkışının üstünde, ve
komut unit kurulamadıysa ya da döküm yazılmadıysa başarısız dönüyor.
Mevcut sunucular için güncellemeye iyileştirme adımı eklendi.

2. BoxTrapper karantina kuyruğu hiç dolmuyordu

Müşteri BoxTrapper'ı açınca sieve kuralı gerçekten çalışıyor ve beklenmeyen
posta karantinaya düşüyor — ama panelde kuyruk ve bekleyen sayacı **sonsuza
kadar 0**. Müşteri tutulan postalarını göremiyor, serbest bırakamıyordu.

Aynı zincirde ikinci kusur: özellik bayrağı var olmayan bir sütundan
okunuyordu, yani her zaman "kapalı" dönüyordu. Sonucu: her filtre veya otomatik
yanıt kaydında sieve yeniden üretilirken BoxTrapper kuralı siliniyordu.

Bayrak artık arayüzün gerçekten yazdığı yerden okunuyor, sieve üretimi tek
yazıcıda birleşti (kurallar birbirini ezmiyor) ve karantina kuyruğu doğrudan
posta kutusundan canlı okunuyor.

3. Kaynak kullanımı grafiğinde tarihler hatalıydı

Veri katmanı sağlamdı (saat dilimleri tutarlı, ölçüm cron'u düzenli). Kusur
tamamen sunum katmanındaydı ve üç seviyedeydi:

• X ekseni insan etiketinden kuruluyordu. `new Date('06.08 10:00')` tarayıcıda

"8 Haziran 2001" veriyor — ay ve gün yer değiştiriyor. Değer geçerli bir
tarih olduğu için koddaki savunma da hiç devreye girmiyordu. Ayın 13'ünden
sonra ise geçersiz tarih → eksenin yarısı 2001, yarısı sıra numarası.

• Alan adları uyuşmuyordu: grafik `cpu_pct`, arka uç `cpu_avg` gönderiyordu →

24 saatlik grafik tüm metriklerde düz sıfır çiziyordu.

• Pencere kova sınırına hizalı değildi: "24 saat" 25 kova, "30 gün" 31 gün

döndürüyordu; eksenin iki ucunda aynı saat etiketi vardı ve uçtaki kovalar
eksik örnekle ortalanıyordu (son gün 127 örnek, tam gün 288).

Artık her noktada makine-okunur zaman damgası var, kovalar hizalı, ölçüm
olmayan aralık `0` değil boşluk olarak çiziliyor, ve çözülemeyen zaman
uydurulmuyor.

İnceleyicinin bulduğu üç ek kusur da düzeltildi: boşluk eşiği artık sunucudan
gelen gerçek kova boyundan türetiliyor (medyandan türetmek, tam da boşluklu
seride çalışmıyordu), "henüz veri yok" açıklaması yeniden görünür oldu, ve
hiç ölçülmeyen MySQL sorgu hızı artık "0" yerine boş dönüyor.

Test tabanı

229 kırık / 1272 geçen. Kırık sınıf kümesi 2026.8.32 tabanıyla birebir aynı
(79 sınıf) — bu sürüm hiçbir testi bozmadı, +28 test ekledi.

ONOXSOFT 2026.8.41 — Posta Taşıma gerçekten çalışıyor + yer kontrolü + yalan kota uyarısı

1. "Hesap askıda olduğu için posta taşıma başlatılamaz" — hesap askıda değilken

`Account::$casts` hesap durumunu bir enum'a çeviriyor. Kapı ise enum
nesnesini metinle karşılaştırıyordu:

```php
if ($account->status !== 'active') // enum !== string → HER ZAMAN doğru
```

Yani hesap aktif olsa bile taşıma başlatılamıyordu: özellik 2026.8.32'den beri
arayüzden hiç çalışmamış.

Uçtan uca test bunu yakalayamamıştı çünkü çekirdeği doğrudan çağırıp
denetleyiciyi atlıyordu; sözleşme testi ise kusuru mühürlemişti — eski kodun
varlığını doğruluyordu. İkisi de düzeltildi.

Ayrıca kapı panelin kendi tanımından daha katıydı: yalnız `suspended` ve
`terminated` engellenmeli; `pending` meşru bir durum. Mesajlar da artık ayrı.

2. Yer kontrolü hiç yoktu

12 GB'lık bir kutu 1 GB kotalı hedefe taşınmaya başlıyor, saatler sonra kota
dolunca yarıda kalıyordu.

• Bağlantı testi artık gerçek boyut ölçüyor. Çok büyük klasörlerde ölçüm

pahalı olduğu için sınır var; ölçülemeyen klasör `0` değil "—" gösteriyor
ve toplam `+` ile işaretleniyor.

• Taşıma başlatılırken seçili klasörlerin toplamı hedef kutu kotasıyla

karşılaştırılıyor; yetmiyorsa başlatılmıyor ve mesaj somut: ne kadar veri,
ne kadar boş yer, hangi kota.

• Sınırsız kota engellenmiyor. Ölçemediğimizde kapı hiç uygulanmıyor.

Canlı doğrulama (gerçek hesap): 6643 mesaj / 8864 MB ölçüldü — INBOX 4917 MB,
Çöp 2090 MB, Gönderilenler 1685 MB.

3. "Kota dolan hesaplar" uyarısı var olmayan sorunu bildiriyordu

Pano "1 hesap %90+ disk kotasında" diyordu. Tetikleyen tek kayıt:

| Ölçüm | Değer |
|---|---|
| `last_quota_pct` (uyarının okuduğu) | %97,67 |
| Aynı satırın `disk_usage_bytes`/`quota_bytes` değeri | %65,25 |
| Diskteki gerçek kullanım | ~%32 (6,5 GB / 20 GB) |
| Hesabın durumu | askıda (9 gündür) |

Yani panel, askıya alınmış bir hesabın donmuş ve kendi satırıyla bile çelişen
bir sayısına bakıyordu.

Yüzde artık sorgu anında hesaplanıyor, yalnız `active`/`pending` hesaplar
sayılıyor, sınırsız kota hesaba girmiyor. Canlı: eski mantık 1 hesap, yeni
mantık 0 — en yüksek aktif hesap %9,9.

Test tabanı

228 kırık / 1244 geçen. Kırık sınıf kümesi 2026.8.32 tabanıyla birebir aynı
(79 sınıf) — bu sürüm hiçbir testi bozmadı.

ONOXSOFT 2026.8.40 — Çapraz-kiracı log sızıntısı, "Kaydet" posta kesintisi, sahte sıfır ölçümler

1. GÜVENLİK: bir müşteri diğerinin ziyaretçi loglarını okuyabiliyordu

`/var/log/onoxsoft-system` tüm müşterilerin erişim loglarını bir arada tutuyor —
ziyaretçi IP'si, istenen URL, referrer, user-agent. KVKK kapsamında kişisel veri.
Dizin `0755` ile oluşturuluyordu. Canlı kanıt:

```
sudo -u onx_<musteriA> head /var/log/onoxsoft-system/<musteriB>-access.log
→ ÇALIŞIYORDU (matrix'te 86, beta'da 122 müşteri sitesi)
```

Paylaşımlı dizin bilinçli bir karardı: OpenLiteSpeed worker'ı `nobody` olarak
koşuyor ve müşterinin `0750` log dizinine yazamıyordu — o yüzden İstatistikler boş,
Bant Genişliği donuk kalıyordu. Ama `0755` gereksizdi: yazan taraf dizinin
sahibi, okuyan panel parser'ı sysapi üzerinden zaten root koşuyor.

Artık `0750` + dosyalar `0640`. Hem vhost yazıcılarında hem güncellemenin
iyileştirme adımında — kod düzeltmesi tek başına bugün açık olan 208 logu
kapatmazdı.

2. Postfix ekranında "Kaydet" posta kesintisi üretebiliyordu

`postfix_config` tablosu kurulum tohumunda donmuş ve gerçekle uyuşmuyor:

| | Panelin DB'si | Sunucudaki gerçek |
|---|---|---|
| virtual_mailbox_domains | `mysql:/etc/postfix/mysql_virtual_domains.cf` | `postconf -m` çıktısında mysql yok |
| virtual_transport | `dovecot` | master.cf'te dovecot transport'u yok |
| smtpd_tls_cert_file | `/etc/letsencrypt/live/mail.onox.com.tr/…` | o yol diskte yok |

Kontrolcü değişen değil tüm tabloyu yolluyor ve `postfix check` bunları
yakalamıyor (sözdizimi bakar, tamamlık değil) → rollback tetiklenmiyor → sanal
alan adlarına gelen tüm posta düşerdi. Yani ilgisiz tek bir alanı değiştirip
Kaydet'e basmak yeterliydi.

Yazıcı artık iki geçişli: önce hepsini doğrula (harita tipi bu derlemede var
mı, transport master.cf'te tanımlı mı, sertifika yolu diskte var mı), tek ret
varsa `main.cf`'e dokunma. Eskiden reddetme döngünün içindeydi ve reddedilen
çağrı bile `main.cf`'i yarım değiştirilmiş bırakıyordu.

Canlı test (gerçek donmuş DB değeriyle): reddedildi, `main.cf` md5 değişmedi.

3. Kaynak kullanımı ekranları sahte sıfır gösteriyordu

`onx-cgroup-read` cgroup yolunu sabit yazıyordu; müşteri süreçleri orada değil.
Dizin yoksa sabit sıfır JSON basıyordu — "hesap boş" ile "hiç ölçemedik"
ayırt edilemiyordu. Artık yol keşfediliyor ve bulunamazsa `measured:false` +
`null` dönüyor. Ölçülemedi, sıfır demek değildir.

4. Beyaz etiket: müşterinin kendi alan adında "ONOXSOFT" yazıyordu

Varsayılan sayfaların gövde metninde marka düz yazılıydı; `${BRAND_NAME}`
yalnız altbilgide kullanılıyordu. Token'a çevrildi, deploy betiğine boş-marka
koruması eklendi.

Test tabanı

229 kırık / 1239 geçen. Kırık sınıf kümesi 2026.8.32 tabanıyla birebir aynı
(79 sınıf) — bu sürüm hiçbir testi bozmadı.

ONOXSOFT 2026.8.39 — DB dökümü sızıntısı kapatıldı, Passkey arayüzü geri geldi

1. GÜVENLİK: panel veritabanının tam dökümü müşteriye okunabiliyordu

Güncelleme anlık görüntüsü `/var/lib/onox/updates/<sürüm>/db.sql` panel
veritabanının tam dökümüdür — tüm admin/bayi/müşteri parola hash'leri, 2FA
sırları, lisans anahtarları, her kiracının verisi.

`mkdir -p` (umask 022 → 0755) + dump 0644 idi; korumayı sağlayan tek şey üst
dizinin moduydu ve iki sunucu arasında sapmıştı. Canlı ölçüm:

```
sudo -u onx_<musteri> head -c 120 /var/lib/onox/updates/*/db.sql → ÇALIŞIYORDU
```

Düzeltme:

• Dizinler 0700, dökümler 0600. Dosya dump'tan önce 0600 ile oluşturuluyor —

yönlendirme dosyayı umask ile açıyordu ve dump saniyeler sürüyordu.

• Mevcut eski dökümler de geriye dönük sıkılaştırılıyor; bu adım olmadan

düzeltme yalnız yeni dökümleri korurdu.

• Budama eklendi. Kod anlık görüntüleri 3'te tutulurken DB dökümleri hiç

budanmıyordu: beta 73 sürüm / 58 GB, matrix 47 sürüm / 55 GB. Artık aynı
politika — en yeni 3 sürüm kalır (geri dönüş penceresi korunur).

2. Passkey (WebAuthn) arayüzü geri geldi

Arka uç zaten çalışıyordu (7 rota, `authorizeLoginUsing` kancası, `User`
sözleşmesi, profil prop'ları) ama arayüz hiç merge edilmemişti: dosyalar
birleşmemiş bir dalda kalmış, yalnız tek bir sunucunun diskinde izsiz duruyordu.
Sonuç: kayıtlı geçiş anahtarıyla giriş çalışıyor, ama kullanıcı anahtar
ekleyemiyor/silemiyordu.

Geri gelenler: `config/passkeys.php` (RP ID + user-handle gizli anahtarı), rol
kapısı middleware'i (yönetim rotaları yalnız admin+bayi), profil sekmesi, giriş
sayfası butonu, `.env.example` anahtarı. Farklar tamamen eklemeydi.

i18n: 26 anahtar × 10 dil birleştirildi, parite korundu (10 × 10248).

Test tabanı

229 kırık / 1236 geçen. Kırık sınıf kümesi 2026.8.32 tabanıyla birebir aynı
(79 sınıf) — bu sürüm hiçbir testi bozmadı.

ONOXSOFT 2026.8.38 — Posta Taşıma: sertifika doğrulaması artık gerçekten çalışıyor

Belirti

Posta Taşıma'da gerçek bir hesap denendiğinde:
"Sunucunun SSL sertifikası doğrulanamadı."

Kök neden

PHP'nin IMAP eklentisi (c-client) TLS el sıkışmasında SNI göndermiyor.
Paylaşımlı barındırmada sunucu, SNI'siz gelen bağlantıya kendi varsayılan
sertifikasını veriyor. Canlı ölçüm (`mail.vavamedya.com:993`):

| Bağlantı | Sunucunun verdiği sertifika |
|---|---|
| SNI'siz (c-client böyle bağlanır) | `CN=sunucu.nitrosistem.com.tr` — barındırıcının kendi adı |
| SNI ile | `CN=*.vavamedya.com` — geçerli Let's Encrypt sertifikası |

Yani sertifika geçerliydi, panel onu göremiyordu. Bu, göç kaynaklarının
neredeyse tamamını etkiliyordu ve kullanıcının tek çıkışı doğrulamayı **tamamen
kapatmaktı** — yani gerçek bir güvenlik kaybı.

Düzeltme

Doğrulamayı artık kendimiz yapıyoruz: PHP akışları SNI gönderir, sertifika
zincirini ve host adını denetler.

• Doğrulama geçmezse hiç bağlanılmıyor.
• Geçerse c-client novalidate ile bağlanıyor (onun kontrolü zaten çalışmıyor).
• STARTTLS (143) yolu da destekleniyor.
• Kullanıcı doğrulamayı bilerek kapattıysa kendi kontrolümüz de çalışmıyor.

Sertifika hatası artık sunucunun hangi ada düzenlenmiş sertifika sunduğunu
söylüyor; yanlış adres anında anlaşılıyor.

Taviz (belgelendi): doğrulama ile asıl bağlantı iki ayrı TCP oturumu olduğu
için teorik bir TOCTOU penceresi var. Alternatifler daha kötüydü: c-client
doğrulaması paylaşımlı barındırmada hiç çalışmıyor.

Canlı doğrulama

Gerçek bir hesapla, doğrulama açıkken: bağlandı, 6639 mesaj / 14 klasör
keşfedildi ve klasör eşlemeleri doğru önerildi.

ONOXSOFT 2026.8.37 — Üretimde hata sayfası sızıntısı, takılan güncelleme, taze kurulum

Bu sürüm bir depo denetiminden çıktı: bugünkü iki canlı kusurun sınıfı
sistem genelinde arandı ve üç ayrı yerde daha aynı desen bulundu.

1. Üretimde hata sayfası ham istisna mesajını sızdırıyordu (GÜVENLİK)

`bootstrap/app.php` içindeki hata yanıtı, `APP_DEBUG=false` olan üretim
sunucularında da `$exception->getMessage()`'ı doğrudan hata sayfasına yazıyordu.
500 üreten herhangi bir sayfa, anonim ziyaretçiye şunları gösteriyordu:

```
SQLSTATE[42S02]: … (Connection: mariadb, Host: 127.0.0.1, Port: 3306,
Database: onoxsoft_panel, SQL: select * from …)
```

Yani tam sorgu, veritabanı adı, host:port, mutlak dosya yolları ve iç sınıf
adları. Saldırgan için bedava keşif. Beta ve matrix'te `APP_DEBUG=false`
doğrulandı — ikisi de bu davranıştaydı.

Kök neden ilginç: düzeltme 7.71 güvenlik sertleştirmesinde **zaten
yazılmıştı** (`SafeExceptionMessage`, 338 satır) ama o daldaki 10 commit main'e
hiç merge edilmemiş. Sınıf beta'nın diskinde duruyordu; main'de onu çağıran kod
olmadığı için ölüydü.

Politika üç kademeli:

| Durum | Davranış |
|---|---|
| 401/403/404/419/422/429/503 | `abort()` metni aynen geçer; yalnız sert sızıntı imzaları (SQL, stack, yol, sınıf adı, servis adresi) taranır |
| 5xx | Ham mesaj asla dışarı çıkmaz; kısa bir hata referansı üretilir, aynı id ham detayla log'a yazılır |
| `APP_DEBUG=true` | Sınıf hiç çağrılmaz — geliştirici deneyimi aynen korunur |

JSON/API yolunda da yalnız 5xx maskelenir; 402 (lisans), 422 (doğrulama) ve 503
(bakım modu) sözleşmeleri dokunulmadan geçer.

Kanıt: düzeltme olmadan `ErrorPageLeakTest` 5 kırık, düzeltmeyle 10/10.

2. Detach modlu güncelleme her seferinde %12'de donuyordu

Yeniden başlatma betiği doğrudan çalıştırmayı deniyordu, ama paket sysapi
betiklerini `0644` ile kuruyor (canlı ölçüm: beta'da 544, matrix'te 540 dosya
`+x` değil):

```
/bin/bash: …/onx-panel-self-update: Permission denied
```

Detached süreç anında ölüyor, transient servis "Deactivated successfully" diyor,
ilerleme %12'de donuyor ve `.log` dosyası dahi boş kalıyordu — başarısızlık
hiçbir yerde görünmüyordu.

Artık yorumlayıcı açıkça veriliyor, `$0` mutlaklaştırılıyor, okunamazsa bilinen
kurulum yollarına düşülüyor ve hiçbiri okunamazsa "başladı" demek yerine
açıkça başarısız olup ilerleme dosyasına yazılıyor.

Canlı doğrulama (beta, betik bilinçli olarak `0644`): düzeltmeden önce log
boştu; şimdi yeniden başlatılan süreç gerçekten koşup girdi doğrulamasına
ulaştı ve hatayı yazdı.

3. Taze kurulumda durum sayfası baştan yalan söylüyordu

2026.8.34–8.36 sürücü sapmasını düzeltti, ama yalnız mevcut sunucularda.
Zincirin taze-kurulum ucu ayrıca kırıktı:

• `StatusComponentsSeeder` bileşenleri `http`/`tcp` olarak kuruyor,
• onları `service` kontrollerine çeviren migration **yalnız üretim

sunucularında** vardı, depoda yoktu (beta'da batch 44 olarak kayıtlı).

Depoda olmayan şey pakete giremez → matrix/169 ve her taze kurulum ondan
mahrumdu. Yeni bir sunucu, `web-server` bileşeni gerçek servisi değil
`http://localhost/up` yoklamasını ölçen bir durum sayfasıyla başlıyordu — ve
yeni `StatusComponentReconciler` de yardım edemiyordu, o yalnız
`check_type='service'` satırlarına bakıyor.

Migration depoya alındı. `self_http` ENUM değerini de o ekliyor —
`StatusChecker` o dalı çalıştırıyor ama izlenen hiçbir migration değeri
tanımlamıyordu.

Ayrıca seeder'da: `env()` → `config()` (config önbelleklenmişse `env()` NULL
döner, `api` ve `panel-ui` endpoint'leri bozulurdu) ve FTP bileşeninin adı
kurulu olmayan yazılımı söylüyordu.

4. Test edilmeyen güvenlik korumaları mühürlendi

Aynı birleşmemiş dalın testleri de geride kalmıştı. Beşi main'e karşı
çalıştırıldı: 37 geçti, 0 kırık — yani korumalar (WHMCS HMAC replay/nonce,
PluginSandbox, health kapsamı, webroot hijyeni, OpenAPI rota paritesi) main'de
var; eksik olan yalnız regresyon kalkanıydı.

`public/.well-known/acme-challenge/manualtest` (12 bayt, elle yapılmış bir ACME
denemesinden kalma) her pakette müşterinin webroot'una gidiyordu; silindi.

Test tabanı

Temiz harness, tam paket: 228 kırık / 1234 geçen. Kırık **sınıf kümesi
2026.8.32 tabanıyla birebir aynı** (79 sınıf) — bu sürüm hiçbir testi bozmadı,
+66 test ekledi.

ONOXSOFT 2026.8.36 — Uptime kartı: ad hizalaması artık hedeften bağımsız

8.34 durum bileşeninin hedefini (systemd unit) düzeltti, 8.35 adını da
düzeltmeye başladı — ama adı yalnızca hedef AYNI ANDA değişiyorsa. Hedefi bir kez
düzeltilmiş bir sunucuda (elle komut, önceki sürüm, başka bir yol) ad artık hiç
güncellenmiyordu.

matrix'te tam olarak bu görüldü: unit `lsws`'e döndü, kontrol başarılı oldu,
ama kart hâlâ "Web Server (Apache) · Çalışıyor" yazıyordu. Yani düzeltmenin
kendisinin kör noktası vardı.

`alignNames()` artık ayrı bir adım: hedefi zaten doğru olan bileşenleri de
tarar ve adda aynı aileden başka bir marka geçiyorsa yalnız o kelimeyi değiştirir
("Web Server (Apache)" → "Web Server (OpenLiteSpeed)"). Marka geçmiyorsa ada
hiç dokunulmaz — "Ana web sunucusu" gibi kullanıcının yazdığı ad korunur.
Açıklama, kategori ve görünürlük hiçbir zaman ellenmiyor.

Test tabanı

Temiz harness, tam paket: 229 kırık / 1178 geçen. Kırık **sınıf kümesi
2026.8.32 tabanıyla birebir aynı** (79 sınıf) — bu sürüm hiçbir testi bozmadı.
Sözleşme testi sayısı 30.

ONOXSOFT 2026.8.34 — Uptime kartı sürücü değişiminde yalan söylüyordu

Belirti

Operasyon Merkezi → Observability → Uptime (24s) kartındaki `web-server`
satırı sabit görünüyordu.

Canlı ölçüm (matrix)

```
web-server endpoint=httpd 24 saatte 886 kontrol BAŞARILI: 0
gerçek adaptör: OpenLiteSpeedAdapter (unit=lsws)
systemctl: httpd=inactive lsws=active
```

Panel, sapasağlam çalışan bir web sunucusunu kalıcı kesinti olarak
gösteriyordu. Kart hardcoded değildi — veri gerçekti, ama yanlış servisi
ölçüyordu.

Kök neden

`SystemServiceImporter` durum bileşenlerini yalnız bir kez oluşturur ("slug
varsa atla"). Bu, kullanıcının düzenlediği ad/açıklamayı ezmemek için doğru bir
karardır. Ama web sunucusu veya MTA sonradan değiştirilirse bileşenin `endpoint`
alanı eski systemd unit'inde donar ve bir daha güncellenmez.

Ters yön daha tehlikeli: eski unit ayakta bırakılırsa (ör. lsws'e geçilmiş ama
httpd durdurulmamış) bileşen "çalışıyor" der ve gerçek web sunucusunun
çöktüğü hiç fark edilmez.

Düzeltme

`StatusComponentReconciler`:

• Unit adına göre uzlaştırır, slug'a göre değil. Sunucular arasında slug

farklı (`web-server`, `mail-postfix`, `ftp-proftpd`, `database-mariadb`); ortak
olan unit kümesidir.

• Yalnız `endpoint` alanını düzeltir. Ad, açıklama, kategori, görünürlük

korunur — kullanıcı emeği silinmez.

• Aktif sürücü okunamazsa hiçbir şeye dokunmaz. Ölçemediğimizde tahmin

yürütmek, yanlış unit'e yazıp izlemeyi büsbütün bozmak demektir.

Üç kancadan çağrılır:

| Kanca | Ne zaman | Neden |
|---|---|---|
| `WebServerManager::switchTo()` başarı yolu | web sunucusu değişince | anında düzeltme |
| `MailServerManager::switchTo()` başarı yolu | MTA değişince | anında düzeltme |
| `onx-panel-self-update` iyileştirme adımı | her panel güncellemesinde | mevcut bozuk durumu onarır |

Üçüncüsü şart: geçiş kodunu düzeltmek, geçişi zaten yapmış sunuculardaki
yanlış hedefi düzeltmez. Bu panelde defalarca yaşanan "kurulumda var,
güncellemede yok" sınıfı tam olarak budur.

Her iki geçiş kancası da `try/catch (\Throwable)` içinde: uzlaştırma hatası
geçişi asla başarısız göstermez — operatörün çalışan bir geçişi geri almaya
kalkması, geçişin kendisinden daha pahalıdır.

Elle onarım

```
php artisan onox:status:reconcile-services
```

Test tabanı

Tam paket, temiz harness (`git archive HEAD` + vendor + derlenmiş varlıklar):

| | kırık | geçen | kırık sınıf |
|---|---|---|---|
| 2026.8.32 (taban) | 229 | 1168 | 79 |
| 2026.8.33 | 229 | 1172 | 79 |
| 2026.8.34 | 229 | 1176 | 79 |

Kırık sınıf kümesi üçünde de birebir aynı — bu iki sürüm hiçbir testi
bozmadı, +8 yeni sözleşme testi ekledi. 229'luk kırık taban bu sürümlerden
öncedir ve ayrıca ele alınacaktır.

2026.8.35 eki — ad da düzeliyor

8.34 hedefi (systemd unit) düzeltti ama adı bıraktı: matrix'te unit `lsws`'e
döndükten sonra Uptime kartı hâlâ "Web Server (Apache) · Çalışıyor" gösteriyordu.
Kart bu kez adıyla yanıltıyordu.

Artık adda eski marka geçiyorsa yalnızca o kelime değiştiriliyor
("Web Server (Apache)" → "Web Server (OpenLiteSpeed)"). Eski marka geçmiyorsa
ada hiç dokunulmuyor — "Ana web sunucusu" gibi kullanıcının yazdığı ad korunur.
Açıklama, kategori ve görünürlük zaten ellenmiyordu.

ONOXSOFT 2026.8.34 — Uptime kartı sürücü değişiminde yalan söylüyordu

Belirti

Operasyon Merkezi → Observability → Uptime (24s) kartındaki `web-server`
satırı sabit görünüyordu.

Canlı ölçüm (matrix)

```
web-server endpoint=httpd 24 saatte 886 kontrol BAŞARILI: 0
gerçek adaptör: OpenLiteSpeedAdapter (unit=lsws)
systemctl: httpd=inactive lsws=active
```

Panel, sapasağlam çalışan bir web sunucusunu kalıcı kesinti olarak
gösteriyordu. Kart hardcoded değildi — veri gerçekti, ama yanlış servisi
ölçüyordu.

Kök neden

`SystemServiceImporter` durum bileşenlerini yalnız bir kez oluşturur ("slug
varsa atla"). Bu, kullanıcının düzenlediği ad/açıklamayı ezmemek için doğru bir
karardır. Ama web sunucusu veya MTA sonradan değiştirilirse bileşenin `endpoint`
alanı eski systemd unit'inde donar ve bir daha güncellenmez.

Ters yön daha tehlikeli: eski unit ayakta bırakılırsa (ör. lsws'e geçilmiş ama
httpd durdurulmamış) bileşen "çalışıyor" der ve gerçek web sunucusunun
çöktüğü hiç fark edilmez.

Düzeltme

`StatusComponentReconciler`:

• Unit adına göre uzlaştırır, slug'a göre değil. Sunucular arasında slug

farklı (`web-server`, `mail-postfix`, `ftp-proftpd`, `database-mariadb`); ortak
olan unit kümesidir.

• Yalnız `endpoint` alanını düzeltir. Ad, açıklama, kategori, görünürlük

korunur — kullanıcı emeği silinmez.

• Aktif sürücü okunamazsa hiçbir şeye dokunmaz. Ölçemediğimizde tahmin

yürütmek, yanlış unit'e yazıp izlemeyi büsbütün bozmak demektir.

Üç kancadan çağrılır:

| Kanca | Ne zaman | Neden |
|---|---|---|
| `WebServerManager::switchTo()` başarı yolu | web sunucusu değişince | anında düzeltme |
| `MailServerManager::switchTo()` başarı yolu | MTA değişince | anında düzeltme |
| `onx-panel-self-update` iyileştirme adımı | her panel güncellemesinde | mevcut bozuk durumu onarır |

Üçüncüsü şart: geçiş kodunu düzeltmek, geçişi zaten yapmış sunuculardaki
yanlış hedefi düzeltmez. Bu panelde defalarca yaşanan "kurulumda var,
güncellemede yok" sınıfı tam olarak budur.

Her iki geçiş kancası da `try/catch (\Throwable)` içinde: uzlaştırma hatası
geçişi asla başarısız göstermez — operatörün çalışan bir geçişi geri almaya
kalkması, geçişin kendisinden daha pahalıdır.

Elle onarım

```
php artisan onox:status:reconcile-services
```

Test tabanı

Tam paket, temiz harness (`git archive HEAD` + vendor + derlenmiş varlıklar):

| | kırık | geçen | kırık sınıf |
|---|---|---|---|
| 2026.8.32 (taban) | 229 | 1168 | 79 |
| 2026.8.33 | 229 | 1172 | 79 |
| 2026.8.34 | 229 | 1176 | 79 |

Kırık sınıf kümesi üçünde de birebir aynı — bu iki sürüm hiçbir testi
bozmadı, +8 yeni sözleşme testi ekledi. 229'luk kırık taban bu sürümlerden
öncedir ve ayrıca ele alınacaktır.

ONOXSOFT 2026.8.33 — Posta Taşıma: canlı testin ortaya çıkardığı üç kusur

2026.8.32 ile gelen Posta Taşıma özelliği beta'da uçtan uca çalıştırıldı:
izole bir test alan adında iki geçici kutu açıldı, kaynağa sentetik mesajlar
yazıldı, göç gerçekten koşturuldu ve sonrasında her şey silindi. Müşteri
kutularına dokunulmadı.

16 kontrolün 3'ü ilk turda kusur ortaya çıkardı. Üçü de **küçük kutuda görünmez,
ilk gerçek müşteri kutusunda pahalı** sınıfındandır — yani kalıp testleriyle
yakalanamazdı, ancak çalıştırarak görülebilirdi.

1. Kaynak kutu değiştiriliyordu (`FT_PEEK` yok)

`imap_body()` `FT_PEEK` olmadan çağrıldığında c-client okuduğu her mesaja
`\Seen` basar. İki sonucu vardı:

• Müşterinin ESKİ kutusundaki tüm mesajlar "okundu" oluyordu. Göçün salt

okunur olduğunu söyleyip karşı tarafın kutusunu değiştirmek kabul edilemez;
eski sağlayıcıdaki kutu müşterinin elindeki tek kopya olabilir.

• Bayrağı bizim okumamız yazdığı için hedefe her mesaj "okundu" düşerdi.

20 bin maili elle okunmamışa çevirmek mümkün değildir.

Bayrak artık gövde çekilmeden önce okunuyor, gövde `FT_PEEK` ile çekiliyor.
Canlı doğrulama: taşımadan önce ve sonra kaynak kutuda okunmuş mesaj sayısı aynı.

2. Göç 200. mesajda sessizce duruyordu

Runner uzun işi turlara böler (`BATCH = 200`) ve klasörü `pending` durumuna geri
yazar. Buna rağmen tur bitiminde göç koşulsuz `completed` işaretleniyordu:

1. Kuyruk işi devam turunu yalnız `running` durumunda tetiklediği için **kendini
yeniden kuyruğa atmıyordu** → göç 200. mesajda duruyor, panel "tamamlandı"
diyordu.
2. Uzak parola hemen silindiği için sonraki tur zaten çalışamazdı.

Yani 205 mesajlık bir kutuda 5 mesaj kayboluyordu ve kullanıcı bunu ancak eski
sağlayıcısını kapattıktan sonra fark ederdi. Artık yarım kalan klasör varsa durum
`running` kalıyor ve parola korunuyor; bitişte silinmeye devam ediyor.

Canlı doğrulama: 205 mesajlık klasörde 1. tur `kopyalanan=200 durum=running`,
2. tur `kopyalanan=205 durum=completed`.

3. Biten iş sahte "başarısız"a düşüyordu

PHP IMAP eklentisi, c-client'ın bıraktığı ve okunmayan her hata/uyarı kaydını
istek sonunda `E_NOTICE` olarak yayar (`PHP Request Shutdown: … (errflg=1)`).
Laravel'in hata yakalayıcısı bunu `ErrorException`'a çevirir.

Yerel kutuya loopback üzerinden `/notls` ile bağlandığımız için c-client **her
göçte** `SECURITY PROBLEM: insecure server advertised AUTH=PLAIN` uyarısı
bırakıyordu. Sonuç: mesajların tamamı başarıyla taşındıktan sonra iş ölümcül
hatayla düşer, "başarısız" işaretlenir ve müşteriye yanlış bildirim giderdi.

Canlı testte tam olarak bu görüldü: 14/14 kontrol geçti, ardından fatal.

`ImapConnector::drainNotices()` eklendi (hem hata hem uyarı yığını — ikisi ayrı).
Her bağlantı kurulumunda, her yazımdan sonra ve `run()` çıkışında (`finally`)
boşaltılıyor. Doğrulama gerçek kuyruk işiyle, ayrı süreçte yapıldı: çıktıda
ölümcül hata yok, göç `completed`.

Sözleşme testleri

Üç kusur da `tests/Unit/Mail/MailMigrationContractTest.php` içinde mühürlendi
(16 → 19 test). Her testin başında neden bulunuyor; bir refactor bu
davranışları sessizce düşüremesin.

Test tabanı — 2026.8.32 notundaki düzeltme

8.32 notunda "507 → 523 test, sıfır hata" yazıyor. Bu ölçüm dar kapsamlıydı.
Repo'dan (`git archive HEAD`) kurulan temiz bir harness'ta tam paket 1405 test
içeriyor ve 228'i kırık — ve bu sayı bu sürümden önce de aynı. Yani:

• Bu sürüm hiçbir testi bozmuyor (229 → 228 kırık, 1168 → 1172 geçen).
• Ama "taban tertemiz" ifadesi tam paket için doğru değildi.

Kırıkların büyük kısmı ortam kaynaklı görünüyor (77'si `ViewException`; derlenmiş
varlıklar eklendiğinde 290'dan 228'e düştü). Ayrıştırma sürüyor; sonuç ayrı
raporlanacak.

ONOXSOFT 2026.8.32 — Posta Taşıma + Operasyon Merkezi Geri Dönüşü

1. Posta Taşıma (IMAP göç) — YENİ

DirectAdmin'in IMAPSync'inin muadili. Panelde şimdiye kadar yalnız e-posta ADRESİ
içe aktarma vardı (CSV); posta İÇERİĞİNİ taşıyan hiçbir şey yoktu — müşteri başka
bir hosting'den geldiğinde binlerce maili elle çekmek zorundaydı.

E-Posta hesapları → Posta Taşıma sekmesinde, tamamı Türkçe bir sihirbaz.

Neden `imapsync` değil

`imapsync` bir Perl betiğidir ve onlarca Perl bağımlılığı ister; AlmaLinux
depolarında (EPEL etkinken bile) paketi YOK — canlıda doğrulandı. Kendi kurulum
adımımızı yazmak, 2026.8.27–8.29'da üç kez düzeltilen *"kurulumda var, güncellemede
yok"* tuzağını dördüncü kez kurardı. PHP IMAP eklentisi üç sunucuda da ZATEN kurulu.

Tam otomatik

• Ayar tespiti: e-posta adresinden. Bilinen sağlayıcılar (Gmail, Outlook,

Yandex, Yahoo, Zoho) tablodan; diğerleri için `imap.` / `mail.` / `webmail.`
DNS'te denenir. Hiçbiri çözülmezse uydurma host önerilmez — elle giriş istenir.

• Klasör eşleme: `[Gmail]/Sent Mail`, `Sent Items`, `Gönderilmiş` → hepsi `Sent`.

Müşterinin özel klasör ağacı korunur.

• Bağlantı testi zorunlu: klasör listesi ve mesaj sayıları taşımadan önce

gösterilir; yanlış bilgiyle kuyruğa iş atılmaz.

• Kuru çalıştırma: hedefe hiçbir şey yazılmadan rapor üretilir.

Dayanıklılık

• İlerleme Cache'te DEĞİL DB'de — eviction/restart bir göçü kaybetmemeli.
• Klasör bazında `last_uid` → worker ölürse baştan başlamaz, en fazla 1 mesaj

tekrarlanır.

• İş kendini parçalayarak yeniden kuyruğa atar; tek job worker'ı saatlerce kilitlemez.
• `tries` + backoff + tur üst sınırı.

Güvenlik

• Uzak parola at-rest şifreli (`encrypted` cast) ve başarı/başarısızlık/iptal

yollarının HEPSİNDE silinir. "Şifreli" etiketi takıp düz metin yazmıyoruz.

• Sahiplik doğrulaması: başka hesabın kutusuna göç engellenir.
• Askıya alınmış hesapta taşıma başlatılmaz; aynı kutuda ikinci göç engellenir.
• Parola JSON/array çıktısından gizli (`$hidden`).

Dovecot'a yazım

Maildir'e doğrudan dosya yazmak yerine localhost IMAP + `imap_append`: Dovecot
dosya adlandırma, index ve kotayı kendi kurallarıyla halleder. Kimlik için webmail
SSO'nun zaten üretimde kullandığı master-user — müşteri parolası saklanmaz.

Spam yok

Taşıma bitince TEK özet; klasör veya tur başına bildirim YOK (2026-07/08'deki iki
spam olayının dersi).

2. Operasyon Merkezi geri geldi

`7beb6a8a` ("prod /opt tam senkronu") 61 dosya silmişti; 41'i
`app/Domain/Operations` altındaki Operasyon Merkezi uygulamasıydı — ayrıca
`config/operations.php`, üç migration, üç konsol komutu, iki Vue sayfası ve altı
sysapi betiği (`php-config-read`, `redis-config-read`, `redis-tune`,
`mysql-config-read`, `mysql-set-global`, `php-system-ini-write`).

Bu bir "prod'dan repo'yu senkronla" işlemiydi: prod'da olmayan bir özellik repo'dan
kaldırıldı. Testleri geride kaldığı için 13 test kırık kaldı ve **kırmızı tabanın
içinde 8 hafta fark edilmedi**.

DERS: prod→repo senkronu tek yönlü uygulanırsa repo'da olup prod'da olmayan her
şeyi siler. Böyle bir senkrondan sonra silinen dosya listesi gözden geçirilmelidir.

3. Test tabanı ilk kez tertemiz

507 → 523 test, sıfır hata. Düzeltilen kırık testlerin hiçbirinde beklenti
gevşetilmedi; üçünde tam tersine kodun bilinçli davranışı korunacak şekilde test
güncellendi (ölçülemedi ≠ hata; sync admin adını ezmez; tek birleşik SSL uyarısı).

`DiskScorerTest` KARARSIZDI: `PackageFactory` `disk_mb`'yi rastgele seçiyordu ve
hesap kotası null iken kod haklı olarak paket kotasına düşüyor — kura null gelirse
geçiyordu. Artık deterministik.

⚠️ Ölçülen ilk taban güvenilmezdi: `/root/onox-pest` harness'ı VERSION 1.2.0'daydı
ve `DnsHealthStatus`, `queue.failed` route'u, `templates/` orada yoktu. Harness
repo'ya senkronlandı.

Kümülatif kapsam

2026.8.24–2026.8.31 eksiksiz dahildir.

ONOXSOFT 2026.8.31 — Sahte Veri, Spam Kaynakları ve Sıfır Kurulum

Çok-ajanlı denetim (5 boyut: spam, fallback, mock/stub, ilk kurulum, hardcoded).
20 bulgu, 14'ü düşmanca doğrulamadan geçti. Hepsi bu sürümde kapatıldı.

1. Panel uydurma veri gösteriyordu

Admin → Mail → Postfix sayfası tamamen sahte veri döndürüyordu: `service: 'active'`,
`pid: 12345`, kuyruk `42` ve 10 satır uydurma mail (sahte gönderen/sebeplerle).
Postfix gerçekten çökmüş olsa bile sayfa "aktif" diyordu — panelin tek görevi olan
şeyi yapmıyor, üstelik gerçek arızayı aktif olarak gizliyordu.

Artık `postqueue-status` / `service-status`'tan okunuyor. Okunamazsa uydurma
YAPILMIYOR: `unknown` dönüyor ve UI'da ayrı bir "Ölçülemedi" durumu var —
"ölçülemedi" ile "durdu" karıştırılmıyor (bu ayrım panelde daha önce yanlış alarm
üretmişti).

Antivirüs: motor kurulu değilken `NoneAntivirusAdapter::scan()` `'clean' => true`
dönüyor ve tarama "Tamamlandı, temiz" kaydediliyordu — sahte güvenlik güvencesi.
Artık motor yoksa tarama `Failed` işaretleniyor.

Mail NoneAdapter: `isInstalled()`/`isRunning()` `true` dönüyordu; sınıfın kendi
docblock'u "production'da kullanılmaz, UI'da kırmızı uyarı" derken kod tersini
yapıyordu. Dürüst `false` oldu.

Yedek şifreleme: panelde açılabiliyor ama hiçbir kod okumuyor —
`RunBackupScheduleJob` zaten "sifreleme uygulanmadi — yedek DUZ-METIN uretiliyor"
uyarısı logluyordu. Yani kod gerçeği biliyor, log doğruyu söylüyor, UI yalan
söylüyordu. Açıklamalar gerçeği söylüyor ve açık bırakılmış ayar kapatılıyor.

2. Müşteriye zarar veren sabit değer

SPF önerisinde RFC 5737 belge IP'si (`198.51.100.42`) gösteriliyordu.
`MAIL_SERVER_IP`'yi yazan hiçbir yer yok — yani her kurulumda. Müşteri bunu
uygularsa SPF gerçek sunucuyu yetkilendirmez ve kendi meşru postaları spam'e düşer;
sessiz ve teşhisi zor bir hasar. Artık panelin gerçek IP tespitine düşüyor;
belirlenemezse `ip4:` bileşeni hiç önerilmiyor (`v=spf1 a mx ~all`).

Let's Encrypt hesap e-postası her kuruluma `admin@onox.com.tr` olarak
tohumlanıyordu: white-label alıcısının sertifika süre-bitim uyarıları satıcıya
gidiyordu. Boş bırakıldı.

Panel SSL portu: `WebServerManager` `PANEL_SSL_PORT` okuyordu ama `install.sh`
`ONOXSOFT_PANEL_SSL_PORT` yazıyor — özel port ayarlansa bile bu yol her zaman 666
kullanıyordu. Tek kaynak `config('onoxsoft.panel.ssl_port')`.

3. Spam kaynakları

• WP-cron `cron.d` dosyasında `MAILTO=""` yoktu ve `>/dev/null 2>&1` yalnız

ikinci komuta bağlıydı; site silinince/taşınınca `cd <docroot>` hatası stderr'e
düşüp postalanıyordu. 5 dk aralıkla yetim başına 288 mail/gün.

• Hesap sonlandırmada `/etc/cron.d/onoxsoft-<user>` ve `onoxsoft-wpcron-*`

temizlenmiyordu. Bu dosyalar root sahipli `/etc` altında olduğu için `userdel -r`
onlara dokunmaz → crond her dakika "ORPHAN (no passwd entry)" basıyor, kullanıcı
adı yeniden kullanılırsa eski komutlar YENİ hesabın kimliğiyle çalışıyordu.

• sysapi log'u (`/var/log/onox/sysapi.log`) logrotate kapsamı dışındaydı; kural

yalnız `/var/log/onoxsoft/*.log` kapsıyordu → her sysapi çağrısı bir satır,
sınırsız büyüme.

4. Sıfır kurulum

• WebDAV adımı Debian/Ubuntu kurulumunu öldürüyordu: `chown apache:apache`

(Debian'da `www-data`) ve `/etc/httpd/conf.d/` (Debian'da yok). `run` die ettiği
için kurulum tam orada bitiyordu. Dağıtım değişkenlerinden türetiliyor +
`a2enmod dav dav_fs` / `a2enconf`.

• Debian'da phpredis hiç kurulmuyordu ama `.env` `REDIS_CLIENT=phpredis` diyor

ve session/cache/queue redis sürücüsünü kullanıyor → panel ilk istekte
"Class Redis not found" ile ölürdü.

• el10'da OWASP CRS kurulmuyordu. Paket yok ve yorumdaki "ayrı kaynaktan gelir

(follow-up)" hiç yapılmamıştı: ModSecurity motoru kuralsız çalışıyor, panel
"CRS aktif" diyordu — sıfır koruma, tam güvence. Kurulum artık
`onx-modsec-crs-update` ile upstream'den kuruyor.

5. Ölü + bozuk kod

`removeAccountCronJobs()` hiçbir yerden çağrılmıyordu ve çağırdığı `cron-remove`
sysapi eyleminin arkasında betik yoktu (`onx-cron-remove` hiç yazılmamış) — biri
bağlasaydı üretimde patlardı. Kaldırıldı; beyaz listeden de çıkarıldı. Gerçek
temizlik `onx-user-terminate` Step 7b'de.

Ayrıca

8.30'daki fail2ban onarım migration'ı yanlış tabloyu (`fail2ban_jails` yerine
`fail2ban_jails_meta`) hedeflemişti; `hasTable` koruması yüzünden **sessizce hiçbir
şey yapmadan** "çalıştı" kaydedilmişti. Düzeltildi + bu hata sınıfını yakalayan test
eklendi (onarım migration'larının dokunduğu tablo şemada tanımlı olmalı).

Kümülatif kapsam

2026.8.24–2026.8.30 eksiksiz dahildir.

ONOXSOFT 2026.8.30 — Denetimin Artık Maddeleri

8.29'da "sonraya bırakılabilir" kovasına konan dört madde kapatıldı.

1. Marka/panel adresi için tek kaynak

Panel adresi her yazıcıda ayrı ayrı, çoğu zaman sabit ONOXSOFT değeriyle
fallback'leniyordu:

```
onx-vhost-add-nginx ${REDIRECT_TO:-https://panel.onoxsoft.com.tr:666/...}
onx-vhost-add-caddy ${REDIRECT_TO:-https://panel.onoxsoft.com.tr:666/...}
onx-vhost-add-ols ${PANEL_URL:-https://panel.onoxsoft.com.tr:666}
```

Çağıran değişkeni göndermediğinde müşteri başka bir firmanın paneline
yönlendiriliyordu. Aynı sızıntı 8.26–8.29 arasında üç ayrı yazıcıda ayrı ayrı
bulundu — çünkü ortak kaynak yoktu.

`scripts/sysapi/_lib/brand.sh` eklendi: `onx_panel_url()` /
`onx_panel_url_or_die()`. Öncelik `PANEL_URL` env → `/etc/onoxsoft/panel-url` →
`.env APP_URL` → `hostname:666`. Değer `http(s)://host[:port][/path]` desenine
uymuyorsa boş döner (bozuk dosya açık yönlendirme yüzeyi açmasın); `user@host`
içeren adres reddedilir. Zorunlu yerlerde `_or_die` yanlış panele yönlendirmek
yerine işlemi durdurur. Üç yazıcı da bu kaynağa çevrildi — yeni bir yazıcı
eklendiğinde doğru davranış artık varsayılan.

2. Çıkış kodu sözleşmesi

Panel `SysapiResult::errorCategory()` ile exit code'u kategoriye çeviriyor
(`5 = critical_rollback_fail`). Ama bazı betikler 5/6/7'yi alakasız anlamlarla
kullanıyordu; sonuç olarak bir kullanıcı hatası panelde "kritik rollback
hatası" olarak görünüyordu:

| Betik | Eskiden | Gerçek anlamı | Şimdi |
|---|---|---|---|
| `onx-account-migrate` | 5 | "confirm:true gerekli" = geçersiz girdi | 1 |
| `onx-account-migrate` | 6 | "bu node kaynak değil" = önkoşul | 2 |
| `onx-account-migrate` | 7 | "snapshot-create başarısız" = çalıştırma | 3 |
| `onx-modsec-install-driver` | 5 | "nginx.conf yok" = önkoşul | 2 |
| `onx-cluster-token-rotate` | 5 | TMP'de doğrulama (commit yok) = çalıştırma | 3 |

`onx-modsec-rule-write:146` 5'te bırakıldı — orada gerçekten rollback başarısız
oluyor, yani doğru kullanım.

Sözleşme `_lib/common.sh`'ta tek kaynakta belgelendi ve `onx_die` artık sözleşme
dışı bir kod verilirse logluyor ve 3'e düşürüyor (panel "unknown" görmesin).
6 ve 7 tanımlı değil.

3. fail2ban `panel-login` şablonu disk gerçeğiyle hizalandı

Şablon (`fail2banTemplates.js`) ve seeder-migration şunu kaydediyordu:

```
filter = panel-login → böyle bir filtre dosyası YOK
logpath = /var/log/onox/panel.log → dizin adı bile farklı (onox/ ≠ onoxsoft/)
```

Diskteki gerçek: `onoxsoft-panel-login` + `/var/log/onoxsoft/panel-auth.log`.
Bu şablondan jail kuran admin sessizce çalışmayan bir jail elde ediyordu. Yeni
kurulumlar düzeltilmiş migration ile doğru geliyor; mevcut kurulumlardaki bayat
satır için onarım migration'ı eklendi (yalnız bilinen-yanlış değerleri düzeltir,
admin özelleştirmesine dokunmaz).

4. Dil dosyası paritesi

`flat.en.json` ve `flat.tr.json` diğer sekiz dilden 8 anahtar fazlaydı —
yani o sekiz dilde WebAdmin giriş alanları, DNS kaydı silme onayı ve parola
alanları çevrilmemişti; kullanıcı ham Türkçe anahtarı görüyordu. Sekiz anahtar
sekiz dile de çevrildi: 10/10 dilde tam parite (10.150 anahtar).

Kümülatif kapsam

2026.8.24–2026.8.29 eksiksiz dahildir.

ONOXSOFT 2026.8.29 — Denetim Düzeltmeleri + Turbo Pasif Ayrıştırma

Çok-ajanlı denetim (5 boyut, düşmanca doğrulama) 20 bulgu üretti, 17'si onaylandı,
3'ü çürütüldü. Bu sürüm onaylananların kritik olanlarını ve açıkça istenen Turbo
pasif ayrıştırmasını kapsar.

1. Panel yönlendirmesi — ikinci yazıcı

`scripts/sysapi/onx-ols-vhosts-unified-rewrite:657` müşterinin `panel.<alan>`
docroot'una index.php üretirken hedefi hiçbir değişkenden okumuyordu:

```
header('Location: https://panel.onoxsoft.com.tr:666/customer/dashboard', ...)
```

2026.8.26'daki çalışma-anı çözümü yalnız `scripts/autodiscover/*` dosyalarına
uygulanmıştı; bu ikinci üretici düzeltmeden kaçmıştı. Bu betik OLS'e geçişte
zorunlu adım olduğundan, white-label bir kurulumda web sunucusu değiştirildiğinde
müşteriler başka bir firmanın paneline yönlendirilmeye geri dönüyordu.

Adres artık `/etc/onoxsoft/panel-url`'den okunuyor; okunamazsa index.php **hiç
yazılmıyor** (yanlış hosta atmaktansa hiç atmamak doğrudur — PHP tarafındaki
`SystemSubdomainProvisioner::panelRedirectUrl()` aynı kararı veriyor).

2. WAF olayları panele hiç yazılmıyordu

`modsecurity_audit_events.uri` `VARCHAR(500)`, yazan kod ise kırpmıyordu. WAF'ın
yakaladığı saldırı URI'leri uzun olduğu için `SQLSTATE[22001]` atıyor ve insert
korumasız olduğundan tüm parti düşüyordu. Canlıda ölçüldü (matrix, 2 günde 22
kez — `onox:modsec:audit-parse` her koşuda başarısız): WAF çalışırken panelin
"Engellenen Kurallar" ekranı boş kalıyordu.

Saldırganın belirlediği tüm kolonlar (`uri` 500, `domain_name` 253, `method` 10,
`rule_tag` 100) kolon genişliğine kırpılıyor; insert satır-bazlı `try/catch` içine
alındı — tek bozuk olay artık partiyi düşürmüyor.

3. Sıfır kurulumu öldüren üç hata

• `-x` kapıları hep FALSE. Kurulum sonu bootstrap adımları

`[[ -x "${ONOX_HOME}/scripts/sysapi/..." ]]` ile kapılıydı; depodaki sysapi
dosyalarının modu `100644` ve boru hattında kaynak ağacına `chmod +x` yok. Kapı
hiçbir zaman açılmıyor, `else` dalı da olmadığı için log'a tek satır düşmüyordu.
Belirti: `pureftpd.passwd` hiç oluşmuyor → her hesapta
`onx-ftp-pure-user-add` exit 2. Çağrılar zaten `bash "..."` ile yapıldığı için
exec bitine gerek yok — 6 kapı `-f` yapıldı.

• `pkg_install X || warn` ölü kod. `pkg_install` içindeki `run`, başarısızlıkta

`die` (yani `exit`) çağırıyor; `||` yalnız errexit'i bastırır, açık exit'i değil.
Opsiyonel sanılan tek bir paket (EPEL10'da phpMyAdmin, grepcidr, restic/rclone/
sshpass) bulunamadığında tüm kurulum ölüyordu. `pkg_install_optional`
(try_run tabanlı) eklendi; yalnız gerçekten opsiyonel 5 çağrı ona çevrildi.
Aynı sebeple `onox:install:service-enforcement` çağrısı da `try_run`'a alındı —
eskiden bu adım patlarsa kurulum admin kullanıcısı oluşmadan ölüyor ve
`ADMIN_TEMP_PASS` hiç basılmadığı için panele giriş imkânsız kalıyordu.

• `_install_web_server_debian` tanımsızdı. `install.sh:1887`'den çağrılıyor ama

hiçbir yerde tanımlı değildi; `set -euo pipefail` altında exit 127. Usage'da
resmen desteklenen Debian 11/12 + Ubuntu 22.04/24.04 kurulumları step 4'te
ölüyordu. Fonksiyon yazıldı (apache2 + gerekli modüller / nginx; OLS için açık
uyarı + apache2'ye düşüş).

4. Roundcube markası — ikinci yazıcı

`scripts/sysapi/onx-webmail-ensure` aynı `config.inc.php`'yi yazan ikinci üretici
olmasına rağmen 8.27'deki marka düzeltmesinden kaçmıştı ve her self-update'te
çağrılıyor. Üstelik sıfır kurulumda config'i çoğu zaman bu betik yazıyor
(`_install_roundcube_rhel`, MariaDB henüz ayakta olmadığı için markalı yazımdan
önce `return 0` ile çıkıyor) — yani sabit ONOXSOFT değerleri istisna değil,
varsayılan yoldu. Değer müşteriye görünür: onox skin'inin giriş ekranı
`support_url`'i link olarak basıyor.

Artık `BRAND_SUPPORT_URL` / `BRAND_NAME` / `/etc/onoxsoft/panel-url`'den türetiliyor
ve mevcut config'teki özel değerler korunuyor.

5. Turbo Önbellek — pasif ayrıştırma

Turbo işlem uçlarının 10'u yalnız "domains satırı var mı" bakıyordu; `domains.status`,
`accounts.status`, `domains.dns_status` hiç okunmuyordu. Askıya alınmış hesabın veya
DNS'i pasif alanın docroot'una drop-in yazılıyor, warm/webp/browser-cache job'ları
kuyruğa giriyordu. Sağlık kontrolü `curl --resolve 127.0.0.1` kullandığı için panel
"açıldı" diyordu — müşteriye hiç ulaşmayan iş üretiliyordu.

Doğru yüklem depoda zaten vardı ama yalnız `TurboAutopilotCommand` içinde
gömülüydü; bu ayrışma hatanın ta kendisiydi.

• `app/Domain/TurboCache/Support/TurboEligibility.php` (yeni) — tek uygunluk

kaynağı. Hosting Hesapları ekranıyla aynı semantik: Askıda = hesap aktif değil,
DNS Pasif = `dns_status = inactive`.

• Kapı yalnız mutasyon uçlarında. Açma/optimizasyon (toggle-on, phase, webp,

defer, htmlopt, rum) pasif sitede `409` döner. Okuma ve purge/kapatma serbest
kalır — askıya alınan sitede yöneticinin drop-in'i temizleyebilmesi gerekir,
aksi halde kalıntı sonsuza kadar kalır.

• `enableAll` artık ortak yüklemi kullanıyor (eskiden yalnız `domains.status`'a

bakıyordu; hesap askıya alınınca `domains.status` değişmediği için askıdaki
hesapların alanları da toplu açılıyordu).

• `BulkTurboEnableJob` iş anında yeniden doğruluyor (kuyruk gecikmesinde hesap

askıya alınmış olabilir) ve `skipped_passive` olayı yazıyor.

• `onox:turbo-heal` pasif sitelerde onarım denemiyor.
• `TurboOverview` her siteye `passive` + `passive_reason`, dönüşe `passive_count` +

`operable_total` ekliyor. Kapsam yüzdesi artık pasifler hariç hesaplanıyor —
eskiden askıdaki siteler paydayı şişirip kapsamı yapay olarak düşürüyordu.

• UI: aktifler üstte, pasifler altta gruplanır; Askıda (turuncu) / DNS pasif

(kehribar) rozeti; pasifte açma butonu kilitli, kapatma/purge açık. 10 dilde tam
çeviri.

6. Hosting hoş geldin maili müşteriye ulaşmıyordu

`SendWelcomeMailOnAccountCreated` alıcıyı `$owner?->email ?: $account->email`
sırasıyla seçiyordu. `owner_user_id` her hesapta dolu olduğundan **sahip her zaman
kazanıyor**, hesabın kendi (müşteri) e-postası hiç kullanılmıyordu. Canlıda ölçüldü
(beta, hesap `onx_safakcekic`): hesap e-postası `onoxyazilim@gmail.com` iken mail
sahibin adresine (`info@onoxsoft.com.tr`) gitti, o kutu var olmadığı için
`550 5.1.1 User unknown` ile bounce etti — müşteri hiçbir şey almadı.

Bu mail geçici parola + FTP bilgisi taşır, yani müşteriye aittir; sahibin/bayinin
kendi bildirimi zaten ayrı kanaldan gidiyor (`notifyResellerOnAccountEvent`). Sıra
ters çevrildi; sahip yalnızca hesapta e-posta yoksa yedek alıcı.

Ayrıca "hosting bilgilerini e-posta ile gönder" tercihi hiçbir şey yapmıyordu:
controller yalnız `admin_notes`'a not düşüyor, listener bayrağı hiç görmüyordu →
kutu işaretlenmese bile parola ve FTP bilgileri e-postayla gidiyordu. Tercih artık
`password_plain` ile aynı transient + cache kalıbıyla provision sonrası ikinci
dispatch'e taşınıyor ve uygulanıyor. Bayrağı taşımayan yollarda varsayılan `true` —
sessizce welcome mail kaybı olmaz.

7. `/etc` artefaktları güncellemede tazelenmiyordu

`onx-panel-self-update` kök `install.sh`'ı çağırmıyor ve `/etc` altına yalnız tek bir
artefaktı tazeliyordu. Dört idempotent adım eklendi:

• `logrotate_ensure` — 7.42'de `su ${WEB_USER} ${WEB_GROUP}` → `su root root`

düzeltilmişti ama güncellenen sunucular bozuk satırla kaldı: root sahipli loglar
(acme-renew, ssl-retry, panel-db-backup) dönmüyor ve `logrotate.service` FAILED
oluyordu. Yalnız dosya yokluğuna değil, bozuk `su` satırına da bakıyor.

• `panel_db_backup_cron_ensure` — eski sunucularda panel DB günlük felaket yedeği

hiç alınmıyordu (2026-06 prod-wipe dersi tam olarak buydu).

• `webdisk_ensure` — kurucu yalnız `install.sh`'tan çağrılıyordu; mevcut

sunucularda WebDisk provizyonu `rclone backend start failed` (exit 3) ile düşüyordu.

• `fail2ban_panel_login_ensure` — aşağıya bakınız.

8. fail2ban `panel-login` jail'i sonsuza kadar 0 ban üretiyordu

Jail `enabled = true` görünüyordu ama iki yönden birden kırıktı:

1. Filtrenin aradığı `[ONOX-AUTH] failed login ... ip=<HOST>` satırını yazan **hiçbir
kod yoktu** — `ONOX-AUTH` dizesi tüm depoda yalnız filtre dosyasında geçiyordu.
2. `logpath` `storage/logs/laravel.log`'a bakıyordu; `LOG_CHANNEL=daily` olduğu için
gerçek dosya `laravel-YYYY-MM-DD.log` ve izlenen dosya aylardır yazılmıyordu.

Sonuç: hesap değiştirerek yapılan tek-IP parola denemelerinde IP-ban katmanı hiç
devreye girmiyordu (mevcut rate limiter e-posta+IP anahtarlı olduğu için saldırgan
her denemede farklı kullanıcı adı vererek onu da baypas edebiliyordu).

`Auth\Events\Failed` dinleyicisi (`LogFailedPanelLogin`) eklendi; satır ayrı ve
sabit adlı bir dosyaya yazılıyor (`/var/log/onoxsoft/panel-auth.log`, yeni
`onox_auth` log kanalı). Parola asla loglanmaz. Filtre `[[ ! -f ]]` kapısından
kurtarıldı (artık her koşuda tazelenir) ve jail bu dosyaya yönlendirildi.

9. `onx-vhost-add` panel sistem yollarını reddediyordu

Birinci doc_root kapısı 7.84'te panel yollarını izinli yapmıştı ama "doc_root yoksa
oluştur" dalı eski dar listede kaldı; `SystemSubdomainProvisioner` tam bu yolları
gönderdiği için `webmail.` / `mail.` / `autodiscover.` / `autoconfig.` vhost'ları
oluşmuyordu. Artık açık bir preflight hatası dönüyor — `mkdir`/`chown` YAPILMIYOR:
`/usr/share/roundcubemail` paylaşılan bir panel yoludur, müşteri hesabına chown
edilirse o müşteri tüm kiracıların webmail kurulumuna yazabilir hâle gelirdi.

10. License heartbeat, KillSwitch'ten önce kurtarma denemiyordu

`onox:license-recover` hiçbir yerden zamanlanmıyordu; tek çağıran self-update'ti.
JWT kaybolduğunda gözetimsiz sunucuda kendiliğinden iyileşme yoktu: 7 fail / 42 saat
sonra lisansı geçerli sunucuda KillSwitch açılıp postfix+dovecot durduruluyordu
(canlı: matrix, 16 kez). İnsan panele girerse `BuyController::tryRecoverLicense`
zaten kurtarıyordu — boşluk tam olarak otomatik/cron yolundaydı.

KillSwitch'ten önce saatte en fazla bir kurtarma denemesi yapılıyor; LCS'ye yük
bindirmemek ve gerçek lisans bitişini maskelememek için tavan konuldu, deneme ve
sonucu açıkça loglanıyor.

11. Release paketleyici bayat vendor/build'i sessizce paketliyordu

Kapılar yalnız "dizin var mı" bakıyordu; composer/npm yoksa betik uyarıp devam
ediyordu. Bayat vendor sunucuda kalıcı olur (self-update composer'ı yalnız
`composer.lock` sha'sı değişince koşturur). İki parite kapısı eklendi:
`vendor/composer/installed.json` ↔ `composer.lock` (laravel/framework sürümü) ve her
`resources/js/Pages/**/*.vue` ↔ `public/build/manifest.json`. İkisi de
`ONOX_ALLOW_STALE_VENDOR=1` / `ONOX_ALLOW_STALE_BUILD=1` ile bilinçli geçilebilir.

Bu sürümde ele alınmayan (denetimde onaylandı, sırada)

• Marka değerleri için ortak `scripts/sysapi/_lib/brand.sh` kaynağı ve tüm

yazıcıların ona çevrilmesi (nginx/caddy fallback sabitleri dahil).

• fail2ban jail adı/logpath uyumsuzluğu: migration `2026_05_16_130000` ve

`resources/js/data/fail2banTemplates.js` ↔ disk gerçeği.

• sysapi exit kodu semantiğinin genelleştirilmesi (1 = geçersiz girdi, 2 = preflight).
• `flat.en.json` / `flat.tr.json` diğer sekiz dilden 8 anahtar fazla (bu sürümden

ÖNCE de vardı).

Kümülatif kapsam

2026.8.24–2026.8.28 eksiksiz dahildir.

ONOXSOFT 2026.8.28 — Vhost Render Kapısı + Kalan Marka Sızıntıları

1. Yeni açılan site 403 veriyordu

Canlı (beta, 2026-08-04): iki yeni site, docroot'ta `index.php` olmasına rağmen
403 döndü. Sebep, `vhconf.conf`'ta yerine KONMAMIŞ bir placeholder'dı:

```
allowBrowse ${OLS_ALLOW_BROWSE}
```

Template bu adı taşıyordu; yazıcı betik ise ismi `OLS_AUTO_INDEX`'e çevirmişti.
Doğru düzeltme buydu — OLS'te `allowBrowse 0` dizin-listelemeyi kapatmaz, **tüm
context'i 403'ler**; listeleme yalnız `autoIndex` ile kapatılır. Ama eski adla
yazılmış placeholder hiç yerine konmadı ve OLS tanımsız değeri 0 okudu.

Siteler 21:04–21:05'te açıldı, betik 21:15'te düzeltildi: aradaki 10 dakikada
yazılan iki vhost bozuk kaldı ve onları hiçbir şey onarmıyordu. Sunucudaki diğer
2185 vhost'ta `allowBrowse 1` literal ve sağlıklıydı.

Düzeltme — iki katman

Önleme (asıl olan). `onx-vhost-add-ols`, `onx-vhost-add-caddy` ve
`onx-vhost-add-nginx` artık render sonucunu kurulumdan ÖNCE denetliyor: geriye tek
bir `${...}` kalmışsa vhost yazılmıyor, hata dönülüyor. Bozuk (403'leyen) bir
vhost yazmaktansa mevcut durumu korumak her zaman doğrudur. Yerine-koyma listesine
güvenmek yetmez — hata zaten template ile betiğin placeholder isimlerinin
ayrışmasından çıktı; bu yüzden çıktının kendisi denetleniyor.

Onarım. `onx-vhost-placeholder-heal` mevcut bozuk vhost'ları tarar, güvenli
varsayılana çevirir (`allowBrowse 1` + `autoIndex 0`) ve OLS'i reload eder.
Tanımadığı bir placeholder görürse dosyayı bozmak yerine yedeği geri alıp raporlar.
`verify` modu hiçbir şey yazmaz. Self-update'e `vhost_placeholder_heal` adımı
olarak bağlandı.

2. Kalan white-label marka sızıntıları

2026.8.27'de üç sızıntı kapatılmıştı; genişletilmiş tarama dördünü daha buldu.

• Panel footer'ı — `PanelFooter.vue` içinde `https://onox.com.tr/security`

SABİT gömülüydü; her white-label müşterisi panelin altında başka bir firmanın
adresini görüyordu. Artık `BRAND_SECURITY_URL` marka ayarından geliyor ve
tanımsızsa link hiç render edilmiyor.
⚠️ Onoxsoft'un kendi kurulumlarında linkin görünmesi için `.env`'e
`BRAND_SECURITY_URL=https://onox.com.tr/security` eklenmelidir.

• "onox.com.tr üzerinden upgrade yap" mesajı — 10 dilde duran, kodda hiçbir

yerden çağrılmayan (orphan) bir i18n anahtarıydı; kaldırıldı.

• i18n örnek metinleri — `mail.onoxsoft.com.tr` ve `hostmaster.onox.com.tr`

placeholder örnekleri `example.com`'a çevrildi (10 dil + kaynak bileşenler).

• `scripts/telegram-token-fix/install.sh` — `PANEL_HOST` sabit

`panel.onoxsoft.com.tr:666` idi; white-label sunucuda çalıştırıldığında başka bir
kurulumun paneline bakıyordu. Artık `/etc/onoxsoft/panel-url` → `.env APP_URL` →
`hostname:666` sırasıyla türetiliyor.

Sabit IP taraması temiz (yalnız test ve yorum satırlarında).

Bilinen, bu sürümde ele alınmayan

`flat.en.json` ve `flat.tr.json` diğer sekiz dilden 8 anahtar fazla taşıyor. Bu
sapma bu sürümden ÖNCE de vardı ve ayrı bir iş olarak duruyor.

Kümülatif kapsam

2026.8.24–2026.8.27 eksiksiz dahildir.

ONOXSOFT 2026.8.27 — Güncellemenin Gerçekten Uygulanması + White-Label Sızıntıları

Bu bakım sürümü iki sınıf sorunu giderir: (1) 8.25/8.26'da paketlenen düzeltmelerin
mevcut sunuculara hiç ulaşmaması, (2) white-label kurulumlara sızan sabit
onoxsoft değerleri.

1. "Pakete girdi" ≠ "uygulandı"

8.25 ve 8.26'nın düzeltmeleri pakete girdi, sürüm numarası yükseldi, self-update
35 adımın hepsine `ok` dedi — ve belirtiler aynen devam etti.

1a. Paylaşılan autodiscover endpoint'i tazelenmiyordu

`scripts/autodiscover/install.sh` YALNIZ `install.sh`'tan (sıfırdan kurulum)
çağrılıyordu; self-update yolunda hiç çalışmıyordu. Sonuç:
`/usr/local/onoxsoft/autodiscover/index.php` ilk kurulumda yazıldığı hâlde kalıyor
ve 8.26'nın çalışma-anı çözümlemesi mevcut kurulumlara ulaşmıyordu.

Canlı doğrulama (169, 2026-08-04): 8.26'ya güncellendikten sonra bile dosya
29 Temmuz tarihliydi ve müşterileri başka bir kurulumun paneline yönlendiriyordu.

Düzeltme: self-update'e `autodiscover_ensure` adımı eklendi. Kurucu idempotent —
mevcut `/etc/onoxsoft/panel-url` dosyasına dokunmaz.

1b. Bozuk cron sarmaları geri alınmıyordu

8.24'ün yetenek kapısı yalnız yeni sarmayı engelliyor. Kapı eklenmeden önce
sarılmış crontab'ları hiçbir şey geri almıyordu: sarılan komut çalışmıyor
(`Failed to start transient service unit: Interactive authentication required`),
cron her turda hatayı postalıyordu.

Canlı doğrulama (matrix, 2026-08-04): 8.26 sonrası da saatte 60 hata maili;
`onx_onoxcom` Maildir 68 MB / 17.018 mesaj, müşterinin Flarum scheduler'ı aylardır ölü.

Düzeltme: `onx-cron-slice-wrap` betiğine `heal` modu eklendi ve self-update'e
`cron_wrap_heal` adımı olarak bağlandı. `heal` yalnız sarılı olup sarması
çalışmayan kullanıcıyı unwrap eder; sarma gerçekten çalışıyorsa dokunmaz, böylece
cgroup izolasyonu bozulmaz.

Genel kural

Mevcut sunucu durumunu değiştiren bir düzeltme, self-update'e idempotent bir
heal adımı eklenmedikçe hiçbir kuruluma ulaşmaz. Doğrulama, adım listesinin `ok`
demesiyle değil, belirtinin canlıda ölçülmesiyle yapılır (kurulu dosyayı grep'le,
maillog'u say).

2. White-label sızıntıları

Panel white-label satılıyor. Kurulum betiğinde ve seeder'da kalan sabit onoxsoft
adresleri o kurulumun müşterilerine görünüyor veya altyapılarını başka bir
firmaya bağlıyordu.

• DNS NS varsayılanı — `PANEL_HOSTNAME` üç segmentli desene uymadığında

`ns3/ns4.onoxsoft.com.tr` yazılıyordu; o sunucudaki her müşteri zone'u başka bir
firmanın nameserver'larına delege oluyor, o firma zone'u barındırmadığı için
çözümleme ölüyordu. Artık kurulumun kendi hostname'inden türetilir.

• Roundcube webmail — `/etc/roundcubemail/config.inc.php` sunucudaki tüm

müşterilerin webmail'i tarafından paylaşılır; `support_url` ve `product_name`
sabit onoxsoft değerleriydi. Artık `BRAND_SUPPORT_URL` / `BRAND_NAME` /
`PANEL_HOSTNAME` üzerinden türetilir.

• Durum sayfası seeder'ı — DNS bileşeni sabit `ns1.onox.com.tr` adresini

izliyordu; her kurulumun herkese açık durum sayfası başka bir firmanın
nameserver'ının sağlığını gösteriyordu. Artık `server_settings.dns_ns1` okunur.

Sabit IP taraması temiz: yalnız test ve yorum satırlarında. `config/branding.php`
ve `.env.example` default'ları bilinçli olarak onoxsoft'tur (env ile geçilebilir).

Kümülatif kapsam

2026.8.24 (posta kuyruğu / kota / sertifika seçimi), 2026.8.25 (cron sarma) ve
2026.8.26 (panel yönlendirme endpoint'i) eksiksiz dahildir.

ONOXSOFT 2026.8.26 — Panel Yönlendirme Endpoint'i

Bu bakım sürümü, `panel.<alanadi>` adreslerinin yanlış kuruluma yönlendirilmesini
kalıcı olarak giderir.

Sorun

`/usr/local/onoxsoft/autodiscover/index.php`, tüm müşterilerin `panel.<alanadi>`
vhost'u tarafından PAYLAŞILAN tek bir dosyadır ve içinde tek bir kurulumun panel
adresi SABİT olarak gömülüydü. Dosyanın depoda karşılığı olmadığı için hiçbir
kurulum/güncelleme adımı onu tazelemiyordu: ilk yazıldığı andaki adres sonsuza
kadar kalıyordu.

Sonuç: müşteri `panel.<kendi-alanı>` adresine girdiğinde kendi paneline değil,
başka bir kurulumun paneline yönlendiriliyordu. Canlı doğrulama (matrix):
`panel.<müşteri-alanı>` → `302` → başka kurulumun `:666/customer/dashboard`
adresi.

Düzeltme

• `scripts/autodiscover/index.php` artık depoda tutulur ve kurulum tarafından

dağıtılır; böylece her güncellemede tazelenir.

• Yönlendirme adresi çalışma anında `/etc/onoxsoft/panel-url` dosyasından okunur.

Panel hostname'i değişse bile yönlendirme kendiliğinden doğru kalır.

• Adres `parse_url` ile doğrulanır (yalnız http/https + host, kullanıcı bilgisi

içeremez) — dosya bozulsa bile açık yönlendirme yüzeyi oluşmaz.

• Adres okunamazsa YANLIŞ bir hosta yönlendirmek yerine 503 ve açıklayıcı mesaj

döner.

• `scripts/autodiscover/install.sh` dosyayı kurar, `.htaccess` izin listesine

ekler ve `/etc/onoxsoft/panel-url` yoksa `PANEL_URL` → `APP_URL` →
`PANEL_HOSTNAME:666` sırasıyla üretir (mevcut dosyaya dokunmaz).

Kümülatif kapsam

2026.8.24 posta kuyruğu/kota/sertifika seçimi ve 2026.8.25 cron sarma düzeltmeleri
eksiksiz dahildir.

ONOXSOFT 2026.8.25 — Cron Sarma ve Panel Adresi

Bu bakım sürümü, müşteri cron işlerini tamamen durduran cgroup sarma hatasını ve
`panel.<alanadi>` yönlendirmesindeki sabit panel adresini giderir.

Müşteri cron işleri yeniden çalışıyor

• `onx-cron-slice-wrap`, kullanıcının KENDİ crontab'ına

`systemd-run --uid=<user> --slice=...` öneki yazıyordu. Ayrıcalıksız bir kullanıcı
system manager'da transient unit başlatamaz; polkit
`org.freedesktop.systemd1.manage-units` için interaktif kimlik doğrulama ister ve
cron ortamında bu imkânsızdır.

• Sonuç: sarılan komut HİÇ çalışmıyor, cron her turda

"Failed to start transient service unit: Interactive authentication required."
çıktısını kullanıcıya postalıyordu. Canlıda ölçülen: bir hesapta 16.705 mesaj /
67 MB, dakikada bir yeni mail; müşterinin gerçek işi (ör. `flarum schedule:run`)
aylardır çalışmıyordu. Bu mailler ayrıca Mail Teslimat Raporları sayfasını
`<user>@localdomain` gönderici ile dolduruyordu.

• Sarma öncesi artık YETENEK KAPISI var: kullanıcının gerçekten transient unit

başlatabildiği kanıtlanmadan crontab'a dokunulmaz; atlanma sebebi
`capability_reason` ile raporlanır. Polkit kuralı eklenirse probe kendiliğinden
geçer ve sarma yeniden etkinleşir.

• `--setenv=HOME` artık `/home/<user>` varsayımı yerine gerçek ev dizininden

(`/home/users/<user>`) türetilir.

Geri alma (unwrap) ilk kez çalışıyor

• Unwrap yolunda iç komut `BASH_REMATCH[1]` ile okunuyordu ancak bu okuma,

zamanlama alanını yakalayan İKİNCİ regex eşleşmesinden SONRA yapılıyordu;
`BASH_REMATCH` ezildiği için komut yerine zamanlama alanı yazılıyor ve crontab
`bad command` ile reddediliyordu. Yani bozuk sarma geri alınamıyordu.

• İç komut artık eşleşme anında yakalanır.
• Yazılan crontab içeriği tam olarak bir satır sonu ile bitirilir; `crontab -u`

sonlandırıcı newline olmayan girdiyi `premature EOF` ile reddediyordu.

• `crontab -u` başarıda stdout'a yazdığı "Backup of ... saved to ..." satırı

aksiyonun JSON çıktısına karışıp çağıranda `jq: parse error` üretiyordu; stdout
yutulur, stderr hata mesajı için yakalanır.

panel.<alanadi> gerçek panele yönlendiriyor

• `subdomainTemplates()` yönlendirme adresini

`config('app.panel_url', 'https://panel.onox.com.tr')` ile üretiyordu.
`app.panel_url` hiçbir kurulumda tanımlı değil (canlı: NULL) → her kurulumda
sabit yedek adres yazılıyor ve müşteri `panel.<kendi-alanı>` adresine girince
kendi paneline değil, başka bir kurulumun adresine yönlendiriliyordu.

• Adres artık sırasıyla açıkça ayarlanmış `app.panel_url` (white-label) ve

`APP_URL` (port dahil) üzerinden türetilir. İkisi de yoksa yanlış bir hostname
yazmaktansa yönlendirme hiç yazılmaz.

ONOXSOFT 2026.8.24 — Posta Akışı ve Sertifika Seçimi

Bu sürüm dört gerçek kesintiyi kapatır: panel bildirim e-postalarının hiç
gönderilmemesi, e-posta kotasının yanlış limitten reddetmesi, sistem alt alan
adlarına yanlış sertifika sunulması ve ModSecurity durumunun panelde yanlış
raporlanması.

Bildirim e-postaları artık gönderiliyor

• `supervisor-mail` Horizon `defaults` içinde tanımlıydı ancak `environments`

listesine hiç eklenmemişti. Horizon yalnızca aktif environment'ta listelenen
süpervizörleri başlatır; bu yüzden `mail` kuyruğunun tüketicisi yoktu.

• 24 Mailable'ın 24'ü de `onQueue('mail')` kullandığından panelin TÜM bildirim

e-postaları (kutu kurulum bilgisi, hoş geldiniz, SSL, yedek, kota, parola,
fatura, askı/sonlandırma, bayi, kötü amaçlı yazılım, sistem uyarısı) Redis'te
birikip hiç gönderilmiyordu.

• Süpervizör production ve local ortamlarına eklendi (production: 2 worker, yavaş

bir SMTP el sıkışması posta akışını bloklamasın).

• Yeni sözleşme testi, `defaults` içindeki her süpervizörün her environment'ta da

tanımlı olmasını ve `onQueue()` ile sabitlenen her kuyruğun bir tüketicisi
bulunmasını zorunlu kılar.

E-posta kotası: ekran ile karar aynı kaynaktan

• `packages.mail_quota_mb` kolonu `default(1024)` ile eklenmişti ve NOT NULL

olduğu için mevcut paket satırlarına da yazılmıştı. Paketin disk kotası ne
olursa olsun (10 GB, 20 GB, hatta "sınırsız") posta toplamı 1 GB'a kilitliydi.

• Ayrıca ekran ile karar FARKLI alanı okuyordu: "Mail Disk Kullanımı" sayfası

`limits.mailbox_total_mb` (hiçbir pakette tanımlı değil → 5120 MB fallback),
enforcement ise `mail_quota_mb` kolonu. Müşteri "5 GB'ın 3,6 GB'ı dolu, yerim
var" görüp 1 GB'dan reddediliyordu.

• Kolon varsayılanı 0 (sınırsız — disk kotasıyla sınırlı) yapıldı ve dokunulmamış

varsayılanda kalmış satırlar veri düzeltmesiyle 0'a çekildi.

• Ekran artık `effectiveMailQuotaMb()` değerini gösterir; 0 ise "Sınırsız" yazar.
• Kapısız ikinci kota rotası (`email.disk-usage.quota.update`) kapatıldı; her iki

rota da aynı `canSetMailQuota` kapısından geçer. Disk tavanı ham `quota_bytes`
yerine `effectiveQuotaBytes()` okur (kolon canlıda neredeyse hep NULL'dı ve
tavan fiilen ölüydü).

Sistem alt alan adlarına doğru sertifika

• `CertificatePathResolver` sabit öncelik listesindeki İLK var olan dosyayı

döndürüyordu; sertifikanın süresine de hostname'i kapsayıp kapsamadığına da
bakmıyordu. cPanel göçünden gelen dar sertifikalar `/etc/onoxsoft/ssl/manual/`
altına düşüyor ve bu yol `/etc/letsencrypt/live/` ÜSTÜNDE olduğu için taze,
doğru multi-SAN AutoSSL sertifikasını kalıcı olarak gölgeliyordu.

• Sonuç: kapsanmayan sistem adı için `vhssl` bloğu yazılmıyor, OLS :443

listener'ın kendi (panelin) sertifikasını sunuyordu — tarayıcıda
"sertifika bu site için geçerli değil".

• Seçim artık en iyi KULLANILABİLİR adayı bulur: süresi geçmiş/henüz başlamamış

adaylar elenir, kalanlar sistem alt alan adlarını kapsama sayısı, SAN genişliği
ve geçerlilik süresine göre puanlanır. Joker sertifikalar RFC 6125'e uygun
şekilde yalnız tek seviye eşleşir. Hiçbir aday çözümlenemezse eski davranışa
güvenli biçimde düşer.

• AutoSSL yenileme sweep'ine üçüncü aday kümesi eklendi: sertifikası taze ve

Active olduğu hâlde sistem alt alan adlarını kapsamayan domain'ler. Bu küme
mevcut kapılardan (A/AAAA + `dns_status` + backoff + rate-limit) geçer, yani
DNS'i olmayan domain için Let's Encrypt kotası yakılmaz. Sweep başına inceleme
sınırı vardır ve sınıra ulaşılırsa sessiz kalmaz, loglanır.

ModSecurity durumu artık doğru raporlanıyor

• OpenLiteSpeed'de otoriter `SecRuleEngine` değeri `httpd_config.conf` içindeki

inline `modsecurity_rules` bloğudur. `onx-modsec-status` bu değeri hiç okumuyor,
yalnız `00-engine.conf`'a bakıyor ve boşsa körlemesine "On" varsayıyordu.

• Durum betiği artık önce otoriter inline değeri okur, `00-engine.conf` yalnız

fallback'tir ve ikisi ayrıştığında çıktıya `engine_drift` bayrağı ile açıklayıcı
bir neden eklenir. Değer bulunamazsa "On" uydurulmaz, `unknown` döner.

• Web sunucusu geçişi ve sürücü yeniden kurulumu artık çalışan motor modunu

kurulumdan önce okuyup `modsec-install-driver`'a geçirir. Önceden mod
gönderilmediği için kurucu varsayılanı (`DetectionOnly`) otoriter bloğa
yazılıyor ve her geçiş WAF'ı sessizce engellemeden düşürüyordu.

Kümülatif kapsam

2026.8.16–2026.8.23 arasındaki AutoSSL DNS kapısı, OLS default-page idempotence,
catch-all listener TLS mirası, Fail2ban büyük filo çıktı sınırı, updater kilit
mirası, PHP modül algılama ve cgroup okuma düzeltmeleri eksiksiz dahildir.

ONOXSOFT 2026.8.23 — Cgroup Okuma Kararlılığı

Bu bakım sürümü, kısa ömürlü kullanıcı cgroup slice'ları okunurken oluşabilen
`sysapi:cgroup-read` aritmetik hatasını giderir.

Kaynak kullanımı denetimi

• `cpu.stat` yalnız tek süreçle okunur ve yalnız tam `usage_usec` anahtarı kabul edilir.
• Okuma sırasında slice kapanırsa kısmi değer ile fallback değeri artık aynı çıktıda

birleşemez; CPU değeri her durumda tek ve doğrulanmış bir tamsayıdır.

• Bellek ve süreç sayaçları aritmetik işlemden önce sayısal olarak doğrulanır.
• Sınırsız veya geçersiz limit değerleri güvenli biçimde `null` döner.
• IO sayaçları harici `grep` zinciri yerine Bash eşleştirmesiyle ayrıştırılır; geçici

dosya değişimleri denetim kaydında sahte hata üretmez.

Kümülatif kapsam

2026.8.21 güncelleme kilidi mirası ve 2026.8.22 ionCube/IMAP modül algılama
düzeltmeleri eksiksiz dahildir. AutoSSL DNS kapısı, sistem alt alanı TLS provision,
posta kotası, lisans özellikleri, Fail2ban/ModSecurity/Turbo/WP-CLI denetim
iyileştirmeleri ve güvenli varsayılan sayfalar bu sürümde korunur.

Canlı doğrulama üç sunucuda sürüm, lisans, servis, OLS idempotence, TLS, kota ve
denetim kayıtları üzerinden yapılmıştır.

ONOXSOFT 2026.8.22 — PHP Modül Algılama Güvencesi

Bu bakım sürümü, güncelleme ön kontrolünde yüklü ionCube veya IMAP modülünün bazı
PHP sürümlerinde yanlışlıkla “eksik” algılanabilmesine yol açan pipe/SIGPIPE
etkileşimini giderir.

PHP ve ionCube algılama

• Panel PHP modül listesi önce eksiksiz okunur, ardından ionCube doğrulaması yapılır.
• `pipefail` açıkken `grep -q` erken çıkışının PHP sürecine SIGPIPE göndererek

sahte hata üretmesi engellenir.

• Panel PHP ve OpenLiteSpeed `lsphp` IMAP denetimleri de aynı güvenli, tam-okuma

davranışını kullanır.

• Gerçek modül okuma hatası ile gerçekten eksik ionCube durumu ayrı mesajlarla

raporlanır.

Birlikte gelen güvenceler

• 2026.8.21 güncelleme kilidi koruyucusu eksiksiz dahildir; OLS/FPM süreçleri

güncelleme kilidini miras alamaz.

• DNS'i sunucuya yönelmeyen alanlar AutoSSL/Let's Encrypt denemesine sokulmaz.
• Sistem alt alanı ve catch-all TLS seçimi sertifikanın gerçek hostname kapsamına

göre yapılır.

• Posta kotası gerçek disk kullanımına göre hesaplanır; lisans özellikleri

güncelleme sonrasında yeniden yüklenir.

• Fail2ban/ModSecurity/Turbo/WP-CLI denetim iyileştirmeleri ve güvenli varsayılan

hosting sayfaları bu pakette korunur.

Sürüm, ionCube 15.5 kullanan PHP 8.2 dahil farklı canlı PHP çıktılarıyla; ayrıca
kilit mirası, OLS idempotence ve fail2ban sözleşme testleriyle doğrulanmıştır.

ONOXSOFT 2026.8.21 — Güncelleme Kilidi Güvencesi

Bu bakım sürümü, panel güncellemesi bittikten sonra OpenLiteSpeed'in güncelleme
kilidini yanlışlıkla taşımaya devam etmesine yol açan dosya tanıtıcısı mirasını
kalıcı olarak giderir.

Güncelleme güvenliği

• Tek-örnek güncelleme kilidi artık ayrı bir `flock` koruyucusu tarafından tutulur.
• Kilit dosya tanıtıcısı updater, OpenLiteSpeed, PHP-FPM veya başka bir çocuk

servise aktarılamaz.

• Gerçek bir güncelleme çalışırken eşzamanlı ikinci güncelleme yine güvenle reddedilir.
• Güncelleme tamamlandığında kilit, yeniden başlatılan servisler çalışmaya devam

etse bile otomatik bırakılır; manuel kilit temizleme gerekmez.

• Kilit girdisi `/run` altında yalnız root tarafından okunabilen geçici dosyada

taşınır ve işlem sonunda temizlenir.

Birlikte gelen düzeltmeler

• DNS'i bu sunucuya yönelmeyen alan adları AutoSSL/Let's Encrypt denemesine alınmaz;

gereksiz başarısız doğrulama ve oran sınırı tüketimi engellenir.

• Sistem alt alanları sertifika SAN/wildcard kapsamına göre provision edilir.
• OpenLiteSpeed catch-all vhost'u tüm güvenli listener'lar arasından hostname'i

gerçekten kapsayan sertifikayı seçer.

• Posta kotası ayrılmış sanal toplam yerine gerçek disk kullanımıyla hesaplanır.
• Lisans özellikleri güncelleme sonrası yeniden yüklenir; Enterprise yetkileri

eski önbellek nedeniyle kilitli görünmez.

• Fail2ban, ModSecurity, WP-CLI ve Turbo denetimleri sınırlandırılmış ve güvenli

çıktı üretir; tekrarlayan gereksiz denetim hataları azaltılır.

• Varsayılan hosting sayfalarından FTP ve benzeri özel hesap bilgileri kaldırılmıştır.

Doğrulama

• Kilit mirası sözleşme testleri ve yaşayan çocuk süreç canary'siyle doğrulandı.
• OLS yapılandırma self-heal işlemi değişiklik yoksa yeniden yükleme yapmaz.
• Paket, kaynak testleri/geliştirme bağımlılıkları, `.env` ve yedek dosyalar için

yayın güvenlik kapılarından geçirilir.

2026.8.17–2026.8.20 arasındaki lisans, fail2ban, OLS idempotence, varsayılan
sayfa ve çoklu listener TLS düzeltmeleri bu sürümde eksiksiz olarak yer alır.

ONOXSOFT 2026.8.20 — Çoklu Listener Hostname Sertifikası

Bu bakım sürümü, eski OpenLiteSpeed kurulumlarında geçerli sunucu hostname
sertifikasının 443 yerine panel 666 listener'ında bulunabildiği düzeni destekler.

Sertifika kapsamına göre seçim

• Catch-all kurulumu tüm güvenli OLS listener'larını tarar.
• Sertifika dosyası `hostname -f` değerini gerçekten kapsıyorsa seçilir; yalnız

dosya adına veya listener portuna güvenilmez.

• Seçilen sertifika doğrudan 443 listener'a aitse miras alınır. Başka bir güvenli

listener'dan geliyorsa catch-all vhost'a açıkça ve zinciriyle bağlanır.

• Hiçbir hostname sertifikası bulunamazsa 443 listener çifti, o da yoksa mevcut

self-signed fallback kullanılır.

Canlı doğrulama

• Matrix ve Beta'da 443 listener mirası değişikliksiz kaldı.
• 169 sunucusunda panel listener sertifikasıyla

`https://server.hazirtasarimlar.net/` HTTP 200 ve geçerli TLS verdi.

• Ardışık OLS self-heal çağrıları `changed=false`, `reloaded=false` döndürdü.

Önceki 2026.8.17–2026.8.19 lisans, fail2ban, OLS idempotence, varsayılan sayfa
ve sistem-domain SSL güvenceleri bu sürümde aynen yer alır.

ONOXSOFT 2026.8.19 — OLS Hostname TLS ve Varsayılan Sayfa

Bu bakım sürümü, OpenLiteSpeed catch-all vhost'unun sunucu hostname
sertifikasını ezmesini ve varsayılan sayfanın 403 dönmesini giderir.

Sunucu hostname için doğru sertifika

• Güvenli 443 listener üzerinde geçerli panel/hostname sertifikası varsa

catch-all vhost bu sertifikayı miras alır.

• Catch-all artık `CN=onoxsoft-default` self-signed sertifikasıyla listener

sertifikasını ezmez.

• Güvenli listener sertifikası bulunmayan eski kurulumlarda self-signed fallback

korunur; HTTPS listener kurulumu kırılmaz.

Varsayılan sayfada HTTP 200

• OLS'nin `nobody` static worker'ı varsayılan sayfanın üst dizimlerine güvenli

biçimde erişebilir; private-key dizini kapalı kalır.

• Eşleşmeyen hostname artık LiteSpeed 403 sayfası yerine markalı ONOXSOFT

varsayılan sayfasını HTTP 200 ile sunar.

Canlı doğrulama

• `https://matrix.onox.com.tr/` geçerli Let's Encrypt hostname sertifikası ve

HTTP 200 ile doğrulandı.

• Ardışık self-heal kontrollerinde `changed=false`, `reloaded=false` ve OLS PID

sabit kaldı.

2026.8.17 ve 2026.8.18'deki lisans, OLS idempotence ve büyük fail2ban filosu
güvenceleri bu sürümde aynen yer alır.

ONOXSOFT 2026.8.18 — Fail2ban Büyük Filo Kalkanı

Bu bakım sürümü, çok sayıda site barındıran sunucularda fail2ban durum
kartının Linux süreç argümanı sınırına takılmasını tamamen giderir.

Sınırlı ve güvenli denetim çıktısı

• Jail başına gösterilen yasaklı IP listesi gibi izlenen dosya listesi de ilk

200 kayıtla sınırlandırılır. Tam sayı ve kesilme bilgisi ayrıca korunur.

• Binlerce vhost erişim günlüğünü izleyen jail'ler artık 128 KB tek-argüman

sınırını aşarak `jq: Argument list too long` hatası üretmez.

• IPv6 adresleri ilk iki nokta karakterinde kesilmeden ayrıştırılır; ekrandaki

IP sayısı fail2ban'ın `currently_banned` değeriyle doğru eşleşir.

Canlı doğrulama

• 2.353 ayrı günlük dosyasını izleyen Matrix jail'iyle gerçek canary yapıldı.
• Sekiz jail'in tamamı hatasız okundu; 36 yasaklı IP'nin 36'sı da doğru

ayrıştırıldı.

• Sözleşme testi hem IP hem dosya listesi sınırını ve IPv6 güvenli

ayrıştırmayı korur.

2026.8.17'deki OLS kesintisiz self-heal ve güncelleme sonrası lisans kurtarma
güvenceleri bu sürümde aynen yer alır.

ONOXSOFT 2026.8.17 — Canlı Canary Güvencesi

Bu bakım sürümü, 2026.8.16 canlı canary denetiminde bulunan iki geçiş
kenar durumunu kapatır.

Kesintisiz OpenLiteSpeed self-heal

• Catch-all listener yapılandırmasının dosya sonu artık deterministik biçimde

normalleştirilir. Her kontrolde bir boş satır birikmesi ve bunun gerçek bir
değişiklik sanılarak OpenLiteSpeed'in yeniden başlatılması önlenir.

• Aynı yapılandırmada art arda yapılan kontroller `changed=false` ve

`reloaded=false` döndürür; çalışan OLS PID'si değişmez.

Güncelleme sonrası lisans sürekliliği

• Panel cache ve bütünlük bakımı tamamlandıktan sonra lisans ayrıca doğrulanır.
• Geçerli JWT geçici olarak okunamıyorsa panel, makine kimliği, bağlı IP ve

kalıcı imza anahtarıyla LCS'den otomatik olarak yeni JWT alır.

• Böylece Enterprise lisanslı sunucularda Container Hosting gibi menüler

güncelleme sonrasında geçici olarak kilitli görünmez.

• Aktif lisansı bulunmayan temiz kurulumlar normal aktivasyon akışında kalır;

kurtarma kontrolü güncellemeyi gereksiz yere geri almaz.

Doğrulama

• OLS listener dosyası iki ardışık canlı çalıştırmada byte-byte karşılaştırılır.
• Lisans kurtarma adımının cache temizliğinden sonra çalıştığı sözleşme testiyle

korunur.

• Dağıtım öncesi PHP/Bash sözdizimi, kod biçimi, hedefli testler ve canlı servis

canary kontrolleri uygulanır.

ONOXSOFT 2026.8.16 — Sistem Domain SSL ve Yükleme Kalkanı

Bu sürüm, wildcard veya çoklu alan adı sertifikalarının `mail`, `webmail`, `panel`,
`webdisk`, `autodiscover` ve `autoconfig` servislerine eksiksiz bağlanmasını sağlar;
Dosya Yöneticisi'ndeki 100 MB yükleme sınırını da gerçek web sunucusu katmanlarıyla
eşitler.

Sistem domainlerinde doğru SSL

• AutoSSL, DNS-01 ve manuel sertifika kurulumundan sonra sertifika yalnız ana vhost'a

değil, altı ayrı sistem vhost'una da yeniden bağlanır.

• Sertifikanın SAN kapsamı doğrulanır. Apex-only bir sertifika yanlışlıkla

`mail.<domain>` gibi kapsamadığı bir servise atanmaz; tek seviyeli wildcard kapsamı
doğru uygulanır.

• Ana vhost artık sistem domainlerini alias olarak sahiplenmez. Böylece OpenLiteSpeed

listener eşleşmesi özel webmail, panel ve otomatik yapılandırma vhost'larını gölgelemez.

• OpenLiteSpeed toplu yeniden yazımında ana domain, bilinen sistem öneki kaldırılarak

bulunur. `.com`, `.com.tr` ve diğer tüm alan adı derinliklerinde aynı yöntem çalışır.

• Diskteki sertifika gerçekten hedef hostname'i kapsamıyorsa OLS vhost'una bağlanmaz;

yanlış ortak ad sertifikası servis edilmesi önlenir.

Panelde gerçek 6/6 durumu

• Sistem Domainleri göstergesi, OpenLiteSpeed'in gerçek

`<kullanıcı>-<hostname>/vhconf.conf` yolunu denetler.

• Çalışan servislerin 0/6 veya pasif görünmesine neden olan eski yol varsayımı

kaldırıldı.

Dosya Yöneticisi 100 MB yükleme düzeltmesi

• OpenLiteSpeed panel vhost'una `upload_max_filesize=100M` ve multipart ek yükü için

`post_max_size=128M` uygulanır.

• PHP-FPM havuzları, Nginx istek sınırı ve OLS/LSPHP ayarları aynı limite hizalandı.
• Kurulum, panel güncellemesi, panel vhost üretimi ve web sunucusu geçişi bu ayarları

yeniden garanti eder; PHP paket güncellemesi limiti tekrar 2M/8M'ye düşüremez.

• Onarım aracı tam idempotenttir: ikinci ve sonraki çalıştırmalar OLS/Nginx

yapılandırmasına boşluk eklemez, dosyayı yeniden yazmaz ve `changed=false` döndürür.

Kesintisiz OpenLiteSpeed bakım döngüsü

• On beş dakikalık web sunucusu self-heal görevi artık yapılandırma değişmediyse

OpenLiteSpeed'i yeniden başlatmaz. Böylece WordPress güncellemesi veya normal ziyaret
sırasında görülebilen anlık `ERR_CONNECTION_REFUSED` penceresi kaldırıldı.

• Catch-all vhost, listener eşlemeleri ve varsayılan sertifika içerik hashleriyle

karşılaştırılır; yalnız gerçek değişiklikte tek kontrollü yeniden yükleme yapılır.

• Komut sonucu `changed` ve `reloaded` alanlarını döndürür; gereksiz yeniden başlatmalar

denetim kaydından ve canlı trafikten ayırt edilebilir.

AutoSSL DNS ve oran limiti koruması

• Public DNS'te hem A hem AAAA kaydı bulunmadığı doğrulanan domainler ACME/Let's Encrypt'e

gönderilmeden temiz biçimde atlanır. Böylece başka firmada, parkta veya DNS'i kaldırılmış
domainler başarısız doğrulama ve oran limiti tüketmez.

• Resolver hatası ile gerçek `NXDOMAIN/NODATA` birbirinden ayrılır. Geçici resolver

belirsizliği sistemi kilitlemez; kanıtlanmış harici IP veya kayıtsız domain ise sertifika
denemesini güvenli biçimde durdurur.

• IPv6-only domainler desteklenir; geçerli AAAA kaydı A kaydı yok diye reddedilmez.

E-posta kotası doğruluğu

• Posta kutusu kotaları fiziksel olarak önceden ayrılmış disk gibi toplanmaz. Her kutunun

kotası kendi üst sınırı, hosting mail kotası ise gerçek toplam kullanıma göre uygulanır.

• Örneğin 10 GB mail alanında iki adet 1 GB kutu bulunması yeni hesap açmayı yanlışlıkla

engellemez; gerçek kullanım toplam limite ulaştığında koruma yine devreye girer.

• Kota göstergesi yüzdesi ve sert limit uyarısı gerçek `usage_bytes` üzerinden hesaplanır;

toplam tanımlı kutu kotası yalnız bilgi amacıyla korunur.

Denetim ve güvenlik araçları dayanıklılığı

• Fail2ban jail durumunda çok büyük yasaklı IP listesi süreç argüman sınırını aşamaz; kart

ilk 200 IP'yi gösterir, tam liste ayrı ayrıntı görünümünde kalır.

• Boş Dovecot giriş günlüğü artık hata değil başarılı boş sonuçtur.
• GitHub CRS API geçici olarak bozuk/limitli yanıt verdiğinde ModSecurity güncelleme kontrolü

JSON ayrıştırma hatası üretmez; kurulu CRS çalışmaya devam eder ve registry durumu raporlanır.

• Yüksek frekanslı salt-okuma ve zamanlanmış uzlaştırma çağrılarının başarılı sonuçları

örneklenir; gerçek başarısızlıklar eksiksiz kaydedilmeye devam eder.

• Başarıyla rollback edilmiş Turbo uyumsuzluk uyarıları altı saatte bir örneklenir;

kırmızı gerçek hata görünürlüğü korunurken aynı güvenli uyarı yüzlerce kez yazılmaz.

• Turbo autopilot DNS'i pasif veya hesabı kapanmış stale domainleri sysapi'ye göndermez;

bulunmayan docroot kaynaklı yinelenen `turbo-dropin` hataları kesilir.

• Çakışan WordPress snapshot işleri tekrar kuyruğunda deneme hakkı tüketmez; yinelenen iş

sessizce düşürülür ve stale kilit iş timeout'undan sonra otomatik açılır.

Lisans ve Container Hosting görünümü

• Enterprise lisansın `ops_containers` yetkisi sunucu tarafında ve menüde aynı wildcard

semantiğiyle değerlendirilir; güncelleme sonrası derlenmiş arayüz ve Inertia önbelleği
birlikte yenilenir.

• Müşteri Container Hosting erişiminde lisans yetkisi ile hosting paketi kotası ayrı

korunur: pakette `container_hosting` açık ve `container_max` sıfırdan büyük olmalıdır.
Böylece lisanslı yönetim ekranı yanlış kilitlenmez, kotasız müşteri de sınırsız kaynak açamaz.

Doğrulama

• Wildcard, apex-only, DNS-01 ve ana vhost alias senaryoları için regresyon testleri

eklendi.

• OLS gerçek vhost yolu, sertifika kapsam kontrolü ve tüm yükleme katmanlarının limit

sözleşmesi otomatik testlerle korunuyor.

• Yükleme onarım aracı gerçek FPM, OLS ve Nginx fixture'larında art arda iki kez

çalıştırılarak dosya hashlerinin değişmediği doğrulanıyor.

• PHP sözdizimi, Bash sözdizimi, kod biçimi ve hedefli Pest testleri uygulanır.
• E-posta kotası, public DNS NODATA, IPv4/IPv6 kararları, OLS sıfır-değişiklik davranışı,

Fail2ban çıktı sınırı ve geçici ModSecurity registry kesintisi regresyon testleriyle korunur.

ONOXSOFT 2026.8.15 — Sistem Domain SSL ve Dosya Yükleme

Bu sürüm, wildcard veya çoklu alan adı sertifikalarının `mail`, `webmail`, `panel`,
`webdisk`, `autodiscover` ve `autoconfig` servislerine eksiksiz bağlanmasını sağlar;
Dosya Yöneticisi'ndeki 100 MB yükleme sınırını da gerçek web sunucusu katmanlarıyla
eşitler.

Sistem domainlerinde doğru SSL

• AutoSSL, DNS-01 ve manuel sertifika kurulumundan sonra sertifika yalnız ana vhost'a

değil, altı ayrı sistem vhost'una da yeniden bağlanır.

• Sertifikanın SAN kapsamı doğrulanır. Apex-only bir sertifika yanlışlıkla

`mail.<domain>` gibi kapsamadığı bir servise atanmaz; tek seviyeli wildcard kapsamı
doğru uygulanır.

• Ana vhost artık sistem domainlerini alias olarak sahiplenmez. Böylece OpenLiteSpeed

listener eşleşmesi özel webmail, panel ve otomatik yapılandırma vhost'larını gölgelemez.

• OpenLiteSpeed toplu yeniden yazımında ana domain, bilinen sistem öneki kaldırılarak

bulunur. `.com`, `.com.tr` ve diğer tüm alan adı derinliklerinde aynı yöntem çalışır.

• Diskteki sertifika gerçekten hedef hostname'i kapsamıyorsa OLS vhost'una bağlanmaz;

yanlış ortak ad sertifikası servis edilmesi önlenir.

Panelde gerçek 6/6 durumu

• Sistem Domainleri göstergesi, OpenLiteSpeed'in gerçek

`<kullanıcı>-<hostname>/vhconf.conf` yolunu denetler.

• Çalışan servislerin 0/6 veya pasif görünmesine neden olan eski yol varsayımı

kaldırıldı.

Dosya Yöneticisi 100 MB yükleme düzeltmesi

• OpenLiteSpeed panel vhost'una `upload_max_filesize=100M` ve multipart ek yükü için

`post_max_size=128M` uygulanır.

• PHP-FPM havuzları, Nginx istek sınırı ve OLS/LSPHP ayarları aynı limite hizalandı.
• Kurulum, panel güncellemesi, panel vhost üretimi ve web sunucusu geçişi bu ayarları

idempotent olarak yeniden garanti eder; PHP paket güncellemesi limiti tekrar 2M/8M'ye
düşüremez.

Doğrulama

• Wildcard, apex-only ve DNS-01 sertifika bağlama senaryoları için regresyon testleri

eklendi.

• OLS gerçek vhost yolu, sertifika kapsam kontrolü ve tüm yükleme katmanlarının limit

sözleşmesi otomatik testlerle korunuyor.

• PHP sözdizimi, Bash sözdizimi, kod biçimi ve hedefli Pest testleri uygulanır.

ONOXSOFT 2026.8.14 — Varsayılan Sayfa Gizliliği ve DNS Gruplama

Bu sürüm, internete açık varsayılan hosting sayfalarındaki bağlantı ve hesap
bilgilerini kaldırır; DNS yanıtı vermeyen sertifikaları SSL/AutoSSL ekranlarında
ayrı ve doğrudan görünür bir gruba taşır.

Varsayılan sayfa güvenliği

• FTP/SFTP sunucusu, portlar, SSH portu, hosting kullanıcı adı ve işlem tarihleri

artık genel placeholder sayfalarında gösterilmez.

• Hassas alanlar yalnız HTML'den değil, önizleme tokenlarından, uygulama

payload'ından ve `envsubst` izin listesinden de çıkarıldı.

• Sysapi, kullanıcı adını yalnız dosya sahipliğini ayarlamak için kullanır; genel

şablona aktaramaz.

• Eski şablon setindeki bağlantı kartları da temizlendi; böylece eski kurulum

yollarından yeniden sızıntı oluşmaz.

Güvenli toplu yenileme

• “Tüm Hesaplara Yeniden Dağıt” işlemi yalnız `ONOX-PLACEHOLDER` işaretini taşıyan

mevcut genel sayfaları yeniler.

• Placeholder bulunmayan docroot oluşturulmaz; müşterinin kendi `index.html`

dosyası hiçbir durumda değiştirilmez.

SSL / AutoSSL görünürlüğü

• DNS kaydı veya nameserver delegasyonu bulunmayan aktif domain sertifikaları,

normal yenilenebilir sertifikalardan ayrı tutulur.

• “DNS Olmayan / Pasif Domainler” grubu hem SSL sertifikaları hem AutoSSL yönetim

ekranında doğrudan görünür; Gelişmiş işlemler veya özel filtre açmak gerekmez.

• Bu grupta yanıltıcı kalan süre gösterilmez ve DNS düzeltilmeden yenileme eylemi

teşvik edilmez.

Doğrulama

• Hassas tokenların şablonlara geri eklenmesini önleyen güvenlik testi eklendi.
• Aktif DNS ve pasif DNS sertifikalarının iki yönetim ekranında doğru gruplandığını

doğrulayan regresyon testleri eklendi.

• PHP, Bash ve üretim Vue/Vite derleme kontrolleri uygulanır.

ONOXSOFT 2026.8.13 — Turbo Fast-Path Tarama Yükü

Bu sürüm, çok sayıda hosting hesabı bulunan sunucularda saatlik Turbo fast-path
temizliğinin müşteri dizinlerini gereksiz yere tekrar tekrar taramasını giderir.

Kök neden

`onox:turbo-fastpath-sweep` altındaki sysapi sürücüsü aynı ağaç olan
`/home/users` ve `/home` yollarını birlikte `find` komutuna veriyordu. Böylece
`/home/users` altındaki bütün müşteri dosyaları iki kez dolaşılıyor; ardından her
site önbelleği sayım, dosya silme ve boş dizin temizliği için üç ayrı kez daha
taranıyordu. 169 sunucusunda bu işlem tek çekirdeğin yaklaşık `%90`'ını kullanıyordu.

Düzeltme

• Müşteri docroot'ları artık Apache, Nginx, OpenLiteSpeed ve Caddy vhost

yapılandırmalarını okuyan ortak `onx_all_docroots` kaynağından alınır.

• Aynı docroot birden çok alan adına bağlı olsa bile yalnızca bir kez işlenir.
• Bayat `index.html` sayımı/silimi ve boş dizin temizliği her site için tek bir

depth-first `find` geçişinde tamamlanır.

• TTL, silinen dosya sayısı ve sysapi JSON yanıt sözleşmesi değişmemiştir.

Güvenlik ve uyumluluk

• Tarama yalnızca vhost yapılandırmasında bulunan gerçek docroot'ların

`wp-content/cache/onox-static` dizinine girer.

• Müşteri içerikleri değil, yalnız TTL'i geçmiş Turbo statik ayna dosyaları silinir.
• Davranış sözleşmesi birim testi ve Bash sözdizimi kontrolüyle korunur.

ONOXSOFT 2026.8.12 — OLS Cache-Buster Koruması

Bu sürüm, botların aynı WordPress içeriğini anlamsız ve sürekli değişen sorgu
parametreleriyle çağırarak sayfa önbelleğini atlatmasını OpenLiteSpeed katmanında
durdurur.

Kök neden

169 sunucusunda `fiberkablotamircisi.com` alan adına GPTBot kimliğiyle saniyede
yaklaşık bir kez `/?f=93891214088`, `/?m=45824189682` benzeri istekler geliyordu.
Her URL benzersiz göründüğü için WordPress cache devre dışı kalıyor, PHP ve
Wordfence uzun süre CPU tüketiyordu.

Düzeltme

• Yalnız `GET` isteklerinde ve sorgu dizesi yalnızca tek harf ile en az yedi

rakamdan oluşuyorsa temiz URL'ye kalıcı 301 yönlendirmesi uygulanır.

• Gerçek sorgular (`?s=arama`, sayfalama, filtre ve UTM parametreleri) etkilenmez.
• Kural hem yeni OLS vhost üretiminde hem web sunucusu geçişindeki toplu OLS

yeniden-yazımında üretilir; sonraki provisioning/switch işlemlerinde kaybolmaz.

• Sistem alt alan adları (mail, webmail, panel, autodiscover/autoconfig) kapsam

dışındadır.

Canlı doğrulama

• Sahte tek-harf sorgusu: 301 → temiz URL → 200, geçerli SSL.
• Normal WordPress arama sorgusu: yönlendirme olmadan 200.
• Etkilenen domainin aktif PHP işçisi: 1 uzun çalışan süreçten 0'a indi.
• Toplam LSAPI işçi sayısı ölçüm anında 95'ten 48'e düştü.

ONOXSOFT 2026.8.11 — WordPress Koruması ve Telemetri Yükü

Bu sürüm, yoğun hesap barındıran sunucularda gereksiz periyodik yükü azaltır ve
WordPress saldırı jail'lerinin kurulum/güncelleme sonrasında gerçekten etkin
kalmasını garanti eder.

Düzeltilenler

• WordPress fail2ban kurucusu artık yalnızca paket içinde beklemiyor; temiz

kurulumda, panel güncellemesinde ve web sunucusu geçişi sonrasında otomatik,
idempotent ve config-test kapılı olarak çalışıyor.

• `GET /xmlrpc.php` taramaları HTTPS yönlendirme durumlarıyla birlikte algılanıyor.

Jetpack/WordPress.com istisnaları korunuyor.

• Olmayan `.php`/webshell yollarını seri biçimde tarayan istemciler için yalnız

404 yanıtlarını sayan, yanlış pozitif eşiği yüksek `onox-php-probe` jail'i eklendi.

• Turbo Shield telemetri özeti artık pencere içinde değişmemiş günlük dosyaları

tekrar okumuyor.

• Ortak vhost/docroot keşfi, her vhost için çok sayıda `basename`, `grep`, `head`,

`awk` ve `stat` süreci açmak yerine Bash içinde tek geçişte ayrıştırılıyor.
Standart `/home/users/<hesap>/...` sahipliği doğrudan güvenli yol bilgisinden
çözülüyor; özel docroot'larda sayısal UID fallback'i korunuyor.

Canlı ölçüm

• 169 sunucusunda Turbo Shield örnekleme süresi aynı sonuçla yaklaşık 36.0

saniyeden 2.59 saniyeye düştü.

• Fail2ban kurucusunun dört filtre smoke testi ve tam config testi geçti; yeni

jail seti rollback korumasıyla etkinleşti.

Güvenlik ve uyumluluk

• Çalışan PHP uçları eşleşmez; PHP probe filtresi yalnız 404 yanıtlarını sayar.
• Meşru WordPress XML-RPC entegrasyonları için mevcut CIDR ve User-Agent

istisnaları korunmuştur.

• Apache, Nginx, OpenLiteSpeed ve Caddy erişim log yolları aynı jail setinde

izlenmeye devam eder.

ONOXSOFT 2026.8.10 — Posta TLS ve Kuyruk Dayanıklılığı

Bu bakım sürümü, üç sunuculu canlı filo taramasında tespit edilen Dovecot TLS DH eksikliğini ve Horizon systemd servisindeki geçersiz MariaDB bağımlılığını kalıcı olarak giderir. 2026.8.9 hesap açma ve SSL doğrulama düzeltmelerinin tamamını içerir.

Düzeltilenler

• Dovecot için RFC 7919 `ffdhe2048` parametreleri güvenli ve hızlı biçimde üretilir; `ssl_dh` yapılandırması hem yeni kurulumda hem bağımsız mail kurulumunda zorunlu hale gelir.
• Panel hostname sertifikası Dovecot'un varsayılan POP3/IMAP sertifikası olarak kullanılır. Global TLS ayarları domain SNI bloklarından önce yüklenerek self-signed fallback ve yapılandırma sıra uyarıları kaldırılır.
• Mevcut sunucular her panel güncellemesinde mail stack self-heal işleminden geçer. Eksik DH dosyası ve yapılandırması atomik olarak oluşturulur, `doveconf` doğrulaması geçmeden Dovecot yeniden yüklenmez.
• POP3/IMAP istemcilerinde görülen `Diffie-Hellman key exchange requested, but no DH parameters provided` TLS hatası giderilir.
• Horizon ve klasik queue worker systemd unit dosyaları artık MariaDB'yi geçerli `mariadb.service` adıyla bekler.
• Önceki sürümlerin hatalı `After=... mariadb` satırı mevcut sunucularda güncelleme sırasında atomik olarak onarılır ve systemd daemon yapılandırması yenilenir.
• Kuyruk servisinin boot sıralaması MariaDB ve Redis hazır olduktan sonra başlayacak biçimde doğrulanır; yeniden başlatmalarda geçici job/provisioning hatası riski azaltılır.
• Apache'den OpenLiteSpeed'e geçişte müşteri adına özel bir Linux grubu varmış gibi çalışan hatalı `chown user:user` kaldırıldı. Ortak `onoxsoft-users` kullanan hesaplarda eski `apache` sahipli WordPress dosyaları artık müşteri UID'sine geçirilir; Wordfence/eklenti yazma döngüsü ve buna bağlı PHP yükü oluşmaz.

Dahil edilen önceki düzeltmeler

• Reseller ve genel hosting hesabı açma yollarındaki `document_root` kaynaklı HTTP 500 koruması.
• Yarım provisioning işlerinin güvenli tekrar denemesi ve ana-domain bütünlük denetimi.
• OpenLiteSpeed geçişi sonrasında wildcard SSL/SNI doğrulama bekleme penceresi ve otomatik self-heal.

ONOXSOFT 2026.8.9 — Hesap Açma ve SSL Doğrulama

Bu bakım sürümü, reseller panelinden hosting hesabı açılırken görülen `SQLSTATE 1364 / document_root` kaynaklı HTTP 500 hatasını giderir ve hesap oluşturma zincirini yarım kayıt bırakmayacak şekilde güçlendirir.

Düzeltilenler

• Reseller hesap açma akışı artık eksik bir ana-domain placeholder satırı yazmaz. Hesap güvenli biçimde `Beklemede` oluşturulur; Linux kullanıcısı, ana domain, DNS, vhost ve sistem subdomainleri tek asenkron provisioning işiyle kurulur.
• Zorunlu `document_root` değeri tüm ham `Domain::create()` yollarında model seviyesinde hesabın home dizininden güvenli olarak türetilir. Gelecekte merkezi provisioner atlanırsa MySQL strict-mode 1364 hatası ve HTTP 500 oluşmaz.
• Provision kuyruğuna geçici olarak ulaşılamadığında kullanıcıya jenerik 500 verilmez; hesap tekrar provision edilebilir `Beklemede` durumunda korunur ve olay denetim kaydına yazılır.
• Provision retry denetimi yalnız `linux_uid` alanına bakmaz. Linux kullanıcısı oluşmuş fakat ana domain zinciri yarıda kalmış hesaplar artık yanlışlıkla tamamlanmış sayılmaz; domain kurulumu yeniden denenir.
• Ana domain satırı asenkron işte henüz oluşmamışken aynı domainle ikinci hesap açılması reseller, admin ve REST API yollarında engellenir.
• Kullanıcı-yüzlü hesap provisioning işleri ayrı `provisioning` kuyruğuna alınır; yedekleme ve tarama gibi uzun arka plan işlerinin arkasında beklemez.
• OpenLiteSpeed graceful reload sonrasında wildcard sertifika SNI doğrulama penceresi 0,75 saniyeden 5 saniyeye çıkarıldı. Sertifika doğru bağlandığı halde yoğun sunucuda görülen sahte self-heal hata raporları kaldırıldı.

Canlı olay düzeltmesi

`zedmak.com` reseller hesabı oluşturulurken ana-domain placeholder insert'i `document_root` alanını göndermediği için istek HTTP 500 ile bitiyordu. Kök neden kaldırıldı; yarım kalan hesabın Linux kullanıcısı, home dizini, domain, DNS veya vhost artığı oluşturmadığı doğrulandı ve güvenli provisioning için ayrıldı.

2026.8.8'de yayımlanan wildcard SSL kalkanı, OLS alias/sertifika koruması ve web sunucusu geçiş kapıları bu pakete dahildir.

ONOXSOFT 2026.8.8 — Wildcard SSL Kalkanı

Bu bakım sürümü, wildcard alan adlarında sertifika dosyası sağlıklı görünmesine rağmen aktif web sunucusunun apex veya varsayılan sertifikayı sunabildiği `ERR_CERT_COMMON_NAME_INVALID` sınıfını kalıcı olarak giderir.

Düzeltilenler

• SSL self-heal artık yalnız diskteki sertifika dosyasını değil, aktif `:443` listener'ının sentetik wildcard SNI adına gerçekten sunduğu sertifikayı da doğrular.
• Sağlıklı wildcard sertifika diskte mevcutsa yeni Let's Encrypt siparişi açılmaz; mevcut sertifika aktif vhost'a yeniden bağlanır ve `*.domain` listener eşlemesi onarılır.
• Öncelikli sertifika dosyası apex-only veya süresi dolmuşsa sonraki sağlıklı wildcard adayları da taranır.
• OpenLiteSpeed toplu vhost rewrite işlemi mevcut `vhAliases` listesini korur; `*.domain` alias'ı artık sabit `www.domain` değeriyle ezilmez.
• OLS cert-link, wildcard vhost'u Apache'den gelen apex-only sertifikaya geri düşürmez; wildcard SAN ve en az 24 saat geçerlilik şartı uygular.
• Web sunucusu geçiş kapısı bütün wildcard vhost'ları loopback üzerinden sentetik SNI ile sınar. Hedef sürücü wildcard sertifikayı sunamıyorsa geçiş kusurlu halde tamamlanmak yerine atomik olarak geri alınır.
• Mevcut wildcard sertifikanın yeniden üretim yapılmadan bağlanabildiğini ve OLS alias/sertifika koruma kurallarını doğrulayan regresyon testleri eklendi.

Canlı olay düzeltmesi

`alcipanfiyatlari.com` wildcard vhost'unda sunucuda geçerli `*.alcipanfiyatlari.com` sertifikası bulunmasına rağmen OLS apex sertifikasını sunuyordu. Sertifika yeniden üretilmeden doğru vhost'a bağlandı; wildcard alias/listener eşlemesi yenilendi ve `umraniyeyapi.alcipanfiyatlari.com` dış HTTPS doğrulaması başarılı hale getirildi.

2026.8.5–2026.8.7 arasındaki OLS geçiş, WordPress Fail2Ban ve denetim sağlığı düzeltmelerinin tamamı bu pakete dahildir.

ONOXSOFT 2026.8.7 — Denetim kaydı ve büyük MySQL sunucusu uyumu

Bu bakım sürümü, güvenli biçimde geri alınmış Turbo uyumsuzluklarının kırmızı sistem arızası gibi görünmesini ve büyük MariaDB sunucularında gerçek veritabanı listesinin 20 saniyede zaman aşımına uğramasını giderir.

Düzeltilenler

• Turbo drop-in veya edge etkinleştirmesi sonrasında origin zaten `500` veriyorsa ve işlem eksiksiz rollback yaptıysa audit sonucu artık `failure` yerine `warning` olarak sınıflandırılır.
• Gerçek vhost/yapılandırma hataları ve rollback doğrulaması olmayan Turbo hataları kırmızı `failure` olarak kalır.
• `mysql-db-list` zaman aşımı, 169 sunucusunda ölçülen yaklaşık 17 saniyelik information_schema taramasına güvenli pay bırakacak şekilde 20 saniyeden 45 saniyeye çıkarıldı.
• Turbo audit sınıflandırması için iki canlı hata imzasını kapsayan regresyon testi eklendi.

2026.8.5 wildcard TLS/OLS rewrite düzeltmeleri ile 2026.8.6 WordPress Fail2Ban düzeltmelerinin tamamı bu pakete dahildir.

ONOXSOFT 2026.8.6 — WordPress trafik koruması

Bu bakım sürümü, WordPress giriş, yorum ve XML-RPC saldırılarının OpenLiteSpeed access loglarında Fail2Ban tarafından görülmesine rağmen geçerli zaman damgası bulunamadığı için sayılmaması sorununu giderir.

Düzeltilenler

• OLS/Apache access log biçimi için açık Fail2Ban tarih deseni eklendi.
• `wp-comments-post.php`, `wp-login.php` ve `xmlrpc.php` filtrelerine gerçek log satırıyla otomatik eşleşme testi eklendi.
• Filtre testi veya Fail2Ban yapı testi başarısız olduğunda mevcut jail ve filtre dosyalarını ayrı ayrı, doğru konumlarına döndüren rollback düzenlendi.
• 169 sunucusunda korumalar etkinleştirildi; canlı loglarda üç jail'in olayları saydığı doğrulandı.
• Koruma etkinleşmeden önce başlamış, uzun süren iki XML-RPC PHP işçisi kontrollü biçimde sonlandırıldı.

Önceki sürümdeki ana düzeltmeler

2026.8.5 ile yayınlanan wildcard TLS, PowerDNS API, OpenLiteSpeed özel `.htaccess`/pretty-URL koruması ve DNS-01 sertifika self-heal değişikliklerinin tamamı bu pakete dahildir.

ONOXSOFT 2026.8.5 «Şemsiye»

Yayın tarihi: 1 Ağustos 2026 · Kanal: stable · Önceki: 2026.8.4 «Mühür»

Bu düzeltme sürümü, panel DNS'sinde joker kayıt kullanan alan adlarında DNS-01
sertifikasının alınmasına rağmen OpenLiteSpeed'in eski apex sertifikasını sunmaya
devam etmesine yol açan eksik sertifika bağını kapatır.

Wildcard SSL ve OpenLiteSpeed

• DNS-01 ile üretilen sertifikaların merkezi `/etc/onoxsoft/customer-ssl` yolu,

sertifika çözümleyicisinin birinci sınıf ve öncelikli kaynağı oldu.

• OLS sertifika bağlayıcısı yeni yönetilen DNS-01 sertifikasını, Apache'den kalan

eski HTTP-01 sertifikasından önce seçer. Böylece `*.alanadi.tld` SAN'ı kaybolmaz.

• Wildcard sertifika alındıktan sonra panel artık yalnız “başarılı” kaydı yazmaz;

aktif web sunucusunun vhost'unu yeni cert/key ile yeniden üretir ve reload eder.

• Vhost yeniden yazılamazsa işlem sessizce başarılı görünmez: sertifika durumu

`error` olur, hata denetim kaydına girer ve panel açık bir uyarı gösterir.

• DNS-01 sonucu sertifika tablosuna issuer, challenge, SAN, gerçek bitiş tarihi ve

dosya yollarıyla kaydedilir; wildcard sertifika mail SNI eşlemesine de bağlanır.

• Wildcard için özel document-root tanımlandıysa SSL vhost yenilemesinde korunur.
• Gecelik SSL self-heal artık panel DNS'si aktif joker vhost'ların gerçekten

`*.alanadi.tld` SAN'ı sunup sunmadığını denetler; apex-only sertifikaları DNS-01
wildcard sertifikasına çevirip web ve mail servislerine otomatik bağlar.

Özel URL kuralları ve OLS geçişi

• Müşteri OLS vhost şablonundaki sabit genel `index.php` kuralı kaldırıldı; üretilen

`${REWRITE_RULES}` bloğu artık gerçekten şablona yazılıyor.

• WordPress/Laravel gibi bilinen CMS'lerin güvenli front-controller kuralı korunurken,

özel `.htaccess` kullanan PHP sitelerinin ürün, kategori, haber ve sayfa kuralları
OLS sözdizimine çevrilip query parametreleriyle birlikte taşınıyor.

• Toplu OLS yeniden-yazım aracı da aynı özel kuralları korur; geçiş veya sonradan

vhost düzeltmesi yapılınca iç sayfalar artık ana sayfaya düşmez.

• Çevirici özel kural bulunan bir `.htaccess` dosyasını işleyemezse genel kurala

sessizce düşmek yerine işlemi durdurur, mevcut çalışan vhost'u korur ve açık hata yazar.

• Toplu yeniden-yazım DNS-01 wildcard sertifikalarını ve geçerli mevcut cert/key

bağlarını korur; URL onarımı SSL'i apex-only sertifikaya geri çeviremez.

PowerDNS DNS-01 hazırlığı

• `onx-pdns-api-enable` preflight'ındaki `pipefail + grep -q` SIGPIPE hatası giderildi.

Kurulu ve çalışan `pdns.service` artık yanlışlıkla “systemd unit yok” sayılmaz.

• Unit varlığı doğrudan systemd `LoadState` üzerinden doğrulanır; bulunmayan servis

yine kapalı güvenlik davranışıyla reddedilir.

Canlı doğrulama

• 169 sunucusunda panel DNS'sindeki `*.profildemircelikfiyatlari.com` kaydı korundu.
• DNS-01 ile `profildemircelikfiyatlari.com` ve `*.profildemircelikfiyatlari.com`

SAN'larını içeren Let's Encrypt sertifikası üretildi ve OLS vhost'una bağlandı.

• `https://esenyurt.profildemircelikfiyatlari.com/` ve ana alan adı TLS doğrulaması

açıkken HTTP 200 verdi; önceki hostname mismatch/HTST kaynaklı erişim hatası kapandı.

• `https://umraniye.santiyeetrafisackapama.com/` için apex + wildcard Let's Encrypt

sertifikası üretildi; TLS doğrulama sonucu `0`, ana sayfa HTTP 200.

• Ümraniye sitesinde `/urunler/`, `/urun/osb-pano` ve `/haberler/1` rotaları ayrı

içerik ve başlıklarla HTTP 200 verdi; “bütün iç URL'ler ana sayfaya gidiyor” hatası kapandı.

Geri dönüş

Güncelleme rollback'li self-update hattıyla uygulanır. Kod, veritabanı, frontend,
integrity manifesti veya sağlık kapılarından biri başarısız olursa önceki çalışan
sürüme otomatik dönüş yapılır. DNS-01 ile alınmış geçerli sertifika dosyaları geri
dönüşte silinmez; önceki web sunucusu yapılandırması korunur.

ONOXSOFT 2026.8.4 «Mühür»

Yayın tarihi: 1 Ağustos 2026 · Kanal: stable · Önceki: 2026.8.3 «Geçit»

Bu düzeltme sürümü, OpenLiteSpeed geçişinden sonra lisans ve müşteri alan adlarının
yanlış SNI sertifikasına düşmesini önler. Lisans istemcisi kanonik API adresini kullanır;
eski ONOX lisans yolları mevcut kurulumlarda otomatik uyarlanır.

Lisans API ve SSL

• Kanonik lisans uç noktası `https://license.onox.com.tr` olarak birleştirildi. Yeni

kurulum, satın alma, heartbeat, kurtarma ve marketplace çağrıları aynı doğrulanmış
SNI hostunu kullanır.

• Eski `https://onox.com.tr/license` ve `https://onox.com.tr/lisans` değerleri yalnız

ONOX adresleri için çalışma anında kanonik hosta çevrilir. Özel veya kurum içi lisans
sunucusu tanımları değiştirilmez.

• TLS doğrulaması açık kalır. Sertifika hostname uyuşmazlığını gizlemek için SSL

doğrulamasını kapatan bir geçici çözüm kullanılmaz.

• OLS sertifika bağlama adımı, alan adına ait mevcut joker/SAN sertifikasını vhost

`vhssl` bloğuna taşır; listener'ın panel sertifikasına sessizce düşülmez.

OpenLiteSpeed geçiş uyumluluğu

• OLS vhost üreticisinin `.htaccess` çeviricisi, self-update'in gerçekten kurduğu

`/usr/local/onoxsoft/bin` konumundan bulunur; eski ve çalışmayan yol geriye uyumlu
yedek olarak korunur.

• `public_html/license -> ../uygulama/public` benzeri doğrudan symlink mount'larının

ön denetleyici kuralları unified rewrite sırasında korunur. `/license/api/*`, `/buy`
ve benzer alt yollar kök sitenin `index.php` dosyasına düşüp 404 üretmez.

• Yalnız güvenli isimli ve gerçek `index.php` içeren doğrudan symlink'ler çevrilir;

WordPress gibi normal dizinlere ek yönlendirme yazılmaz.

Canlı doğrulama

• Matrix'te 517 OLS vhost doğru sertifikasına bağlandı. `onox.com.tr`,

`license.onox.com.tr` ve `get.onox.com.tr` geçerli `*.onox.com.tr` sertifikasıyla
doğrulandı.

• Lisans tier API'si TLS doğrulaması açıkken HTTP 200 verdi; Matrix lisansı otomatik

kurtarıldı ve Enterprise planı 28 Haziran 2028 bitiş tarihiyle yeniden görüldü.

• Heartbeat başarıyla JWT yeniledi; lisans nedeniyle durdurulan Postfix, Dovecot,

Rspamd ve ClamAV servisleri tekrar aktif doğrulandı.

• Beta, Matrix ve 169 sunucularının lisans istemci adresleri kanonik hosta taşındı;

üç sunucudan da API ve sertifika doğrulaması başarılı geçti.

Geri dönüş

Güncelleme tam rollback'li güncelleyiciyle uygulanır. Kod, veritabanı, frontend,
integrity manifesti veya sağlık kapılarından biri başarısız olursa önceki çalışan
sürüme otomatik dönüş yapılır.

ONOXSOFT 2026.8.3 «Geçit»

Yayın tarihi: 1 Ağustos 2026 · Kanal: stable · Önceki: 2026.8.2 «Gözcü»

Bu sürüm; web sunucusu geçişlerini tek bir atomik sağlık kapısında birleştirir,
OpenLiteSpeed altında 503 üreten vhost/LSAPI kaynak taşmasını sınırlar ve sysapi,
ModSecurity, logrotate ile büyük hesap taramalarının denetim sonuçlarını güvenilir
hâle getirir. Geçiş tamamlanamazsa eski çalışan sürücü portlarıyla birlikte otomatik
geri alınır; yarım geçiş başarı olarak raporlanmaz.

---

Web sunucusu geçişleri

• Apache, Nginx, OpenLiteSpeed ve Caddy için panel `:666` ile müşteri `:80/:443`

listener'larının sahibi artık kod, servis ekranı ve yönetim arayüzünde aynı aktif
sürücü olarak gösterilir.

• Geçiş motoru eski sürücüyü durdurduktan sonra üç portun da boşalmasını bekler; hedef

sürücü doğrulanamazsa aynı üç portu serbest bırakıp önceki çalışan sürücüyü geri getirir.

• Panel vhost üretimi, müşteri vhost göçü ve OpenLiteSpeed unified rewrite işlemleri artık

zorunlu kapıdır. Eksik veya bozuk tek bir vhost sessizce atlanıp “başarılı” gösterilmez.

• OpenLiteSpeed büyük vhost filolarında unified rewrite için gerçekçi süre tanınır; işlem

sonunda servis durumu ve yapılandırılmış sonuç birlikte doğrulanır.

• İki dakikalık web sunucusu watchdog'u artık yalnız veritabanındaki etkin sürücüyü yeniden

başlatır. OLS etkin olduğunda pasif Apache'yi kaldırıp `80/443/666` portlarını çakıştıran
eski davranış kaldırıldı; sürücü çözülemezse yanlış servisi başlatmak yerine açık alarm verir.

• Watchdog ile geçiş motoru aynı `/run/onoxsoft/webserver-switch.lock` kilidini kullanır.

Veritabanı sürücü kaydı henüz eski değerdeyken watchdog'un geçiş ortasında eski sunucuyu
yeniden başlatması ve portları hedef sürücüden geri alması engellenir.

• OpenLiteSpeed'e geçmeden önce aktif domain'lerin kullandığı tüm PHP sürümlerinin karşılık

gelen `lsphp` çalışma zamanları ve temel eklentileri hazırlanır. Eksik bir sürümü daha eski
PHP'ye sessizce düşürmek yerine geçiş trafiğe dokunmadan önce açık hatayla durur.

• Apache PHP-FPM havuzundaki hesap limitleri ile güvenli `.user.ini` direktifleri OLS

`phpIniOverride` yapılandırmasına taşınır. Bellek, yükleme, zaman aşımı, oturum dizini,
`open_basedir` ve devre dışı fonksiyonlar sürücü değişiminde kaybolmaz.

• Eski veya içe aktarılmış OLS listener map'lerinde ana müşteri vhost'unun `webmail.*`,

`panel.`, `mail.` ve otomatik yapılandırma adreslerini gölgelemesi temizlenir. Ayrı sistem
vhost'u varsa kesin eşleşme ona bırakılır; müşteri wildcard ve diğer alias'ları korunur.

• WordPress ve diğer CMS sitelerinin `.htaccess` dosyasındaki güvenli alan-adı yönlendirmeleri

OLS front-controller kurallarından önce taşınır. Apache'de çalışan eski→yeni alan adı 301'i
geçişte kaybolup eksik bir `index.php` üzerinden 500 üretmez.

• Servis raporu `openlitespeed` anahtarını doğru `lsws` birimine eşler ve pasif Apache'yi

panel servisi gibi göstermeyerek geçiş sonrası yanlış kırmızı alarmı önler.

Sysapi çıktı güvenilirliği

• Ortak JSON yazıcısı yalnız JSON standardına uygun sayıları tırnaksız üretir. `curl`

bağlantı kuramadığında gelen `000` değeri artık geçersiz JSON sayısı oluşturmaz.

• Yapılandırılmış sonuç bekleyen sağlık kapıları, exit code `0` olsa bile eksik veya bozuk

JSON'u açık tanı mesajıyla reddeder. Böylece “unknown” hatasının gerçek çıktıyı saklaması
önlenir.

• OpenLiteSpeed WebAdmin `:7080` ön hazırlığı servis henüz kapalıyken `http_code: 0`

döndürür; OLS başladıktan sonra listener ve gerçek HTTPS cevabı ayrıca zorunlu doğrulanır.

• Başarılı fleet polling çağrılarının örnekleme anahtarı artık domain/hesap payload'ına göre

çoğalmaz. `record-list`, salt-okuma `wp-cli`, cgroup, SSL, posta ve servis durum okumaları
15 dakikalık pencerede komut başına tek sağlık izi bırakır; tüm hatalar ve mutasyonlar
hedef payload'ıyla eksiksiz denetlenmeye devam eder.

• Büyük hesapların disk taraması düşük CPU/I/O önceliğinde ve 30 saniyelik kontrollü bütçeyle

çalışır. Zaman aşımı artık `exit 124` denetim hatası veya yanlış `0 B` kota değeri üretmez;
son doğru kullanım ve güncellenme zamanı korunur.

• Turbo toplu durum taraması, yüzlerce OLS sistem alt alanı yapılandırmasını okumadan önce eler.

Büyük vhost filolarında `sysapi:turbo-list` 30 saniyelik köprü bütçesini aşmaz.

• Autopilot canary'sinin siteyi koruyarak tamamen geri aldığı drop-in uyumsuzluğu gerçek sistem

arızası gibi kırmızı kaydedilmez; 12 saatlik back-off korunarak beklenen uyumluluk uyarısı olur.

• ModSecurity denetim günlüğü, dağıtımın mevcut httpd/nginx logrotate kurallarıyla ikinci kez

kaydedilmez. OLS günlüğü için systemd'ye yalnız `/usr/local/lsws/logs` yazma izni verilerek
günlük logrotate işinin salt-okunur dosya sistemi hatasıyla topluca durması önlenir.

• OWASP CRS 3.3.10'daki XML öznitelik güvenlik kuralları OLS için eski sürüme düşürülmez.

Yalnız OLS parser'ının desteklemediği `901181` geri-alma aksiyonu sürücüye özel atomik
uyumluluk kopyasından çıkarılır; XML öznitelik denetimi açık kalır ve kurallar eksiksiz yüklenir.

OpenLiteSpeed 503 ve kaynak izolasyonu

• Müşteri vhost'larının LSAPI süreçleri ortak `apache` UID'si yerine ilgili hosting hesabı

UID/GID'siyle çalışır. Sistem alt alan adlarının paylaşımlı sistem havuzu korunur.

• Müşteri başına LSAPI havuzu yoğun paylaşımlı sunucular için beş worker ile sınırlandı;

boş worker'lar 60 saniyede temizlenir. Yüzlerce vhost'un teorik olarak binlerce PHP
süreci açıp `fork()` baskısı ve 503 üretmesi engellenir.

• Bellek ve süreç tavanları müşteri havuzu başına güvenli sınırlara çekildi. Yeni vhost

üretimiyle mevcut vhost'ların unified rewrite yolu aynı ayarları kullanır.

Doğrulama ve geri dönüş

• Shell → gerçek süreç → `SysapiResult` hattı için zero-padded HTTP kodu regresyon testi

eklendi.

• OLS aktivasyonu bozuk yapılandırılmış çıktıda durur ve çıktının kendisini tanıda gösterir.
• Panel sürücü sahipliği testi, panel adapter'ının aktif sürücüden ayrışmasını engeller.
• Watchdog sözleşme testi, pasif Apache'nin OLS/Nginx/Caddy yanında yeniden başlatılmasını

ve port yarışının ileride geri gelmesini engeller.

Canlı doğrulama

• Aynı imzalı paket Beta, Matrix ve 169 üretim sunucularında tam rollback'li güncelleyiciyle

uygulandı; üç kurulumda da migration, cache, sysapi, health ve panel kapıları geçti.

• Üç sunucuda OLS aktif, Apache pasif bırakıldı; `80/443/666` portlarının tamamının sahibi

OpenLiteSpeed olarak doğrulandı.

• OLS yapılandırma testi, ModSecurity SQLi duman testi, günlük logrotate görevi, PHP IMAP

modülleri ve panel sağlık URL'leri canlıda yeniden kontrol edildi.

• 169 sunucusundaki zehirli sayısal crawler sorguları PHP'ye ulaşmadan `410`, olmayan PHP

dosyası taramaları `404` dönecek şekilde daraltıldı; normal site ve gerçek PHP yolları açık kaldı.

Güncelleme

Sistem → Güncellemeler ekranından kurulabilir. Güncelleme öncesi kod ve veritabanı
snapshot'ı alınır; migration, web sunucusu aktivasyonu veya sağlık kapısı başarısız olursa
önceki çalışan sürüme otomatik geri dönüş uygulanır.

2026.8.2 «Gözcü»

Yayın tarihi: 1 Ağustos 2026 · Kanal: stable · Önceki: 2026.8.1 «Amiral»

Bu sürüm; domainlerin gerçek DNS/IP durumunu görünür kılar, yoğun sunucularda
zamanlayıcı kaynak taşmasını önler, uzak yedekleme sonrasında yerel diskin
gereksiz büyümesini durdurur ve panel genelindeki dil ile sysapi denetimlerini
tutarlı hâle getirir.

---

Domain, NS ve IP sağlık uyarıları

• Domainin yetkili NS sunucuları, public DNS yanıtı ve gerçek A/IP sonucu ayrı

ayrı denetlenir.

• Domain park servisine düşmüşse, hiç IP yanıtı vermiyorsa veya beklenen sunucu

IP’sinden farklı bir adrese gidiyorsa yönetici panosunda kırmızı uyarı oluşur.

• Sağlık sonucu ve son kontrol zamanı saklanır; geçici resolver hataları doğru

DNS sonucu gibi gösterilmez.

• DNS sağlık alanları mevcut kurulumlara migration ile eklenir.

Panel dili ve durum etiketleri

• active, suspended, pending ve benzeri ortak durum kodları merkezi

dil sistemine bağlandı.

• Hesap seçici ve e-posta yönetimi dâhil aynı durumun geçtiği ekranlarda Türkçe

karşılıklar kullanılır; diğer panel dilleriyle uyum korunur.

• Ham İngilizce durum kodlarının farklı bileşenlerde yeniden görünmesini önleyen

ortak çeviri eşlemesi eklendi.

Google Drive yedekleri ve yerel disk kullanımı

• Google Drive veya başka bir offsite hedef başarıyla doğrulanmadan yerel kopya

silinmez; tek kopya güvenliği korunur.

• Uzak tam hesap yedeği posta verisini kapsıyorsa ikinci bir yerel posta arşivi

oluşturulmaz.

• Root korumalı yedek dizinleri artık panel kullanıcısının doğrudan dosya

kontrolüne bırakılmaz. Dosya varlığı güvenli, salt-okuma sysapi üzerinden
toplu doğrulanır.

• Diskte bulunduğu hâlde yanlışlıkla “yerelden silinmiş” işaretlenen kayıtlar

otomatik düzeltilir; böylece Google Drive göndericisi bu dosyaları atlamaz.

• Günlük offsite güvenlik ağı yalnız son 24 saati değil, gönderilmemiş tüm yerel

yedekleri tarar. Başarılı yüklemeden sonra yerel kopya politika gereği
temizlenir.

• Tamamlanmış taşımalardan kalan geçici arşivler ve yerel yedek sapmaları için

güvenli temizleme/uzlaştırma akışları eklendi.

Zamanlayıcı ve yüksek yük dayanıklılığı

• Laravel zamanlayıcısı süreç genelinde flock ile tekilleştirildi; bir dakika

turu uzasa bile ikinci bir bakım turu üstüne binmez.

• /etc/cron.d altında kalıp Cronie tarafından ikinci görev gibi okunabilen

eski zamanlayıcı yedekleri güvenli yedek dizinine taşınır.

• Çok sayıda vhost taranırken sahip adı için her dizinde NSS sorgusu yapmak

yerine sayısal UID kullanılır ve /etc/passwd eşlemesi bir kez kurulur.
Böylece systemd-userwork süreçlerinin binlerce çoğalıp RAM ve load tüketmesi,
panelde 503/zaman aşımı üretmesi engellenir.

• Swap bulunmayan yoğun kurulumlarda bakım turlarının sistemi tamamen

kilitlemesine karşı kurulum ve canlı onarım kontrolleri güçlendirildi.

Sysapi ve denetim kaydı düzeltmeleri

• apache-modules-list, cron-audit-read, turbo-dropin,

turbo-edge ve wp-cli işlemlerindeki gerçek kök hatalar giderildi.

• Apache modül algılama farklı servis/paket düzenleriyle uyumlu hâle getirildi.
• Turbo ve WordPress salt-okuma kontrolleri başarısız işlem gibi raporlanmaz;

başarılı polling kayıtları örneklenerek denetim kaydı seli önlenir.

• Başarısız işlemler görünür kalır; hata gizleme veya kör “başarılı” sonucu

üretilmez.

PHP 8.2 IMAP kurulumu

• Kurulum ve güncelleme aktif PHP çalışma zamanını ayırt eder.
• OpenLiteSpeed/LSPHP 8.2 ile Remi PHP 8.2 için doğru IMAP paketi ve eklentisi

idempotent biçimde kurulur, etkinliği gerçek PHP binary’siyle doğrulanır.

• E-posta kimlik doğrulama ekranındaki yanlış veya elle uygulanması gereken

paket talimatı kaldırıldı.

---

Canlı doğrulama

• 2026.8.2 temiz yükseltme ve migration akışı üç üretim sunucusunda doğrulandı.
• Tek zamanlayıcı zinciri, kilit davranışı ve yoğun vhost taraması canlı yük

altında test edildi; kullanıcı çözümleme işçisi taşması oluşmadı.

• Google Drive hedefi, yerel kayıt uzlaştırması ve yalnız başarılı offsite

kopyadan sonra silme güvenlik kapısı doğrulandı.

• Panel, müşteri siteleri, MariaDB, Redis, OpenLiteSpeed ve ONOX servisleri

yükseltme sonrasında sağlık kontrollerinden geçti.

Güncelleme

Sistem → Güncellemeler ekranından kurulabilir. Güncelleme öncesi kod ve
veritabanı snapshot’ı alınır; migration veya sağlık kapısı başarısız olursa
otomatik geri dönüş uygulanır.

2026.8.1 «Amiral»

Bu amiral sürüm, yoğun yük veya geçici sysapi erişim sorununun panelde
“servis durdu”, “0 kayıt” ya da “işlem başarılı” gibi yanlış bir sonuca
dönüşmesini engeller. Taşıma ve web sunucusu geçişleri de doğrulanmadan
tamamlanmış sayılmaz.

Yük altında doğru ve hızlı sağlık görünümü

• Sağlık ölçümleri `fresh`, `stale`, `last_good`, `collecting`,

`partial` ve `unavailable` durumlarıyla taşınır.

• Yeni ölçüm zaman aşımına uğrarsa son sağlıklı veri ve yaşı gösterilir;

eski veri hiçbir zaman güncelmiş gibi, ölçüm hatası da “durduruldu” veya
sıfırmış gibi sunulmaz.

• Servis ekranı her unit için ayrı `systemctl` çağrısı yapmak yerine tek,

süre sınırlı toplu systemd sorgusu kullanır.

• Firewall dinleyicileri, fail2ban ve ClamAV ölçümleri veri alınamadığında

boş/başarılı sonuç üretmez; kullanıcıya ölçümün durumu açıkça gösterilir.

• Arka plan yenilemeleri tekilleştirilir ve kontrollü geri çekilmeyle yeniden

denenir; hata sessizce yutulmaz.

Başarısız kuyruk işleri

• Panodaki “Başarısız işler” uyarısı artık genel log sayfasına değil, gerçek

kuyruk yönetim ekranına gider.

• Tek iş veya tüm işler yeniden denenebilir; kayıt gerçekten başarısız işler

tablosundan ayrılmadıysa işlem başarılı sayılmaz.

• Tek kayıt silme ve tüm başarısız kayıtları temizleme işlemleri açık onayla

yapılır.

• Kendini periyodik olarak yenileyen sağlık probe’ları son denemede de hata

verirse durum UI ve loglarda korunur; operatörün elle düzeltemeyeceği yinelenen
kayıtlarla `failed_jobs` tablosu doldurulmaz.

Taşıma ve web sunucusu geçiş güvenliği

• cPanel taşıması tamamlanmadan önce hesap doktoru hem onarım hem temiz

doğrulama geçişini çalıştırır.

• Hedef hesabın web sunucusu için ana domain, vhost yükleme ve sentetik joker

host istekleri uçtan uca doğrulanır.

• Domain envanteri okunamazsa kontrol başarılı varsayılmaz; geçiş veya taşıma

fail-closed davranır.

• Apache panelin `:666` arka ucu olarak çalışırken nginx/Caddy müşteri

sürücüsüyle karıştırılmaz; OpenLiteSpeed ise kendi gerçek yapılandırma
testinden geçer.

• Web sunucusu geçişinde vhost sayımı, sağlık kapısı veya HTTP/joker kontrolü

başarısız olursa yeni sürücü kalıcılaştırılmaz ve önceki çalışan sürücüye
güvenli geri dönüş uygulanır.

• OpenLiteSpeed LSAPI kullandığı için Apache/nginx’e ait FPM havuzu kontrolleri

OLS hesaplarında yanlış arıza üretmez.

Yayın kapısı

Stable dağıtım öncesinde AlmaLinux 9/10 üzerinde aşağıdaki matrisin tamamı
geçmelidir:

1. Temiz kurulum ve `2026.7.87` sürümünden yükseltme.
2. Apache, nginx, OpenLiteSpeed ve Caddy geçişleri ile geri dönüş senaryoları.
3. cPanel taşıması; ana domain, addon domain ve joker domain doğrulamaları.
4. Kontrollü CPU/IO yükü altında panel sağlık ekranları ve sysapi zaman
aşımı senaryoları.
5. Başarısız kuyruk işini yeniden deneme, tek silme ve toplu temizleme.

Bu matris tamamlanmadan sürüm stable kanalına yükseltilmemelidir.