Proxmox Otomasyon Serisi Faz 3: Zabbix Agent 2 (7.0 LTS), Rsyslog (QRadar TCP ve Disk Destekli Kuyruk) ve Güvenlik Ajanları

Bu rehber, Proxmox Otomasyon Serisi'nin dördüncü modülüdür ve tamamlanmış bir altyapı fazının üzerine inşa edilen ilk katmandır. Faz 2; seri numaralarıyla etiketlenmiş disklerin LVM ve XFS katmanlarından geçirilip bağlanması, çalışan makinede kesintisiz disk genişletme, VM açılışında kalıcılığını kanıtlayan reboot testleri ve aygıt harfleri (sdb, sde...) tamamen yer değiştirdiğinde dahi sistemin ayakta kaldığını gösteren saha oturumlarıyla kapatılmıştı.

Makineler mevcut, veriyi tutuyor ve reboot sonrasında sorunsuz ayağa kalkıyor. Bu noktada ana soru değişir: Artık soru "makine ayakta mı?" değil, "makinenin içinde neler oluyor?" sorusudur. Bu sorunun yanıtı konuk (guest) makinenin dışından verilir; bu yanıtın makine içindeki ayağı ise her zaman bir ajandır (agent).

Faz 3, provizyon edilen her sanal makineye üç temel ajan rolü kazandırır:

1. İzleme Ajanı (Monitoring): Merkezi bir sunucunun makineyi kontrol edebilmesi için resmi 7.0 LTS deposuna sabitlenmiş Zabbix Agent 2.
2. Log Yönlendirme (Logging): Makinenin tüm sistem loglarını kurumsal QRadar mimarisine uygun şekilde TCP üzerinden ve disk destekli bir kuyruk mekanizmasıyla dışarı aktaran rsyslog yapılandırması.
3. Güvenlik Ajanları (Security): Homelab ortamında lisanslanması mümkün olmayan kurumsal güvenlik yazılımlarını (Trend Micro Deep Security ve ManageEngine) simüle eden, bir belirteç sözleşmesi (marker contract) arkasında çalışan stub yükleyiciler.

Her üç bileşen de serinin felsefesine sadık kalınarak; numaralandırılmış, bağımsız, idempotent, tek bir değişken dosyasından beslenen ve yeşil recap çıktısı vermeden önce kendi yaptıklarını bizzat doğrulayan Ansible playbook'ları olarak dağıtılır.

---

Faz 3'de ne var?

Planlama aşamasında community rolleri, bir Graylog konteyneri ve basit echo komutlarıyla çalışan sahte betikler düşünülmüştü. Canlıya alınan mimarideki sapmalar birer taviz değil; saha testlerinin getirdiği teknik zorunluluklardır:

İlk Planlanan	Canlıya Alınan	Teknik Gerekçe
community.zabbix.zabbix_agent rolü	Özel 04_zabbix_agent.yml playbook'u	Ubuntu 26.04 için resmi 7.0 LTS deposu zorunluluğu; kontrol düğümüne koleksiyon kurmadan ansible.builtin içinde kalma hedefi.
Ayrı Zabbix sunucusu VM'i (Docker, 4 GB)	ctrl-01 üzerinden zabbix-get doğrulaması	Bu fazın teslimatı sunucu değil ajandır. Soket sorgusu tüm yolu kanıtlar; sunucu isteğe bağlı hafif LXC'ye bırakıldı.
Graylog konteyneri / tam rsyslog sunucusu	ctrl-01 üzerinde tek satırlık socat dinleyicisi	QRadar TCP desenini test eden en hafif uç nokta. Altyapıyı şişirmeden kuyruk akışını tam doğrular.
*.* @@receiver:514 (tek satır yönlendirme)	Disk destekli kuyruğa sahip omfwd aksiyonu	Tek satırlık kural hedef kapandığında log düşürür. Kuyruk mekanizması hedef gelene kadar logları diske depolar.
Basit kabuk betikleri (touch /opt/...)	Sürüm sapma alarmlı marker sözleşmesi	Yükleyici iskeleti prodüksiyon standardındadır; yarın lisans geldiğinde yalnızca yükleme gövdesi güncellenir.

Dizin Ağacı ve Dosya Rolleri

ansible/
├── inventory/group_vars/
│   └── provisioned.yml             # Ajan değişkenleri ayrıştırıldı, sadece depolama şeması kaldı
├── playbooks/
│   ├── vars/
│   │   └── agent-layer.yml         # Ajan katmanının tek gerçek kaynağı (Single Source of Truth)
│   ├── tasks/
│   │   └── wait_for_apt.yml        # İlk açılış dpkg/apt kilit yarışını çözen geçit görevi
│   ├── templates/
│   │   ├── zabbix_agent2.conf.j2   # Dinamik ajan yapılandırma şablonu
│   │   ├── 50-qradar-forward.conf.j2 # Disk kuyruklu rsyslog yönlendirme şablonu
│   │   └── install.sh.j2           # Marker sözleşmesine bağlı stub yükleyici
│   ├── 04_zabbix_agent.yml         # Zabbix kurulum ve 5 adımlı doğrulama playbook'u
│   ├── 05_rsyslog_forward.yml      # Log yönlendirme ve sözdizimi doğrulama playbook'u
│   └── 06_security_agents.yml      # Güvenlik ajanları stub dağıtımı ve drift denetimi

Kapsam Sınırları

• Kapsam İçi: Zabbix Agent 2'nin resmi 7.0 LTS reposundan pini, disk destekli TCP rsyslog kuyruğu, lisanslı ajanlar için marker sözleşmeli stub altyapısı, ctrl-01 üzerinde oturum bağımsız dinleyici ve saha doğrulamaları.
• Kapsam Dışı: Prodüksiyon QRadar / Zabbix sunucu kurulumları, TLS sertifika yönetimi, log ayrıştırma kuralları ve alarm dashboard'ları (bu katmanın tek amacı misafir makinedeki ajan omurgasını ayağa kaldırmaktır).

---

Zabbix Agent 2: Sürüm Sabitleme ve Doğrulama

İzleme tarafında klasik Zabbix ajanı yerine Go ile yeniden yazılan Zabbix Agent 2 tercih edildi. Klasik ajan her metrik için yeni bir alt süreç (fork) açarak kaynak tüketirken, Agent 2 eklenti mimarisi ve kalıcı tek bir TCP bağlantısı üzerinden aktif kontrolleri yürütür.

Neden Community Değil?

1. Resmi Depo Sabitlemesi: Ubuntu 26.04 (resolute) için kararlı paket sağlayan güncel ana dal 7.0 LTS serisidir. Üçüncü taraf bir rolün varsayılan değişkenlerine güvenmek yerine bu bağımlılık doğrudan kod içinde sabitlendi.
2. Sıfır Dış Bağımlılık: Kontrol düğümüne harici Ansible Galaxy koleksiyonları eklenmedi, tüm akış ansible.builtin modülleriyle çözüldü.
3. Operasyonel Şeffaflık: Arka planda onlarca task çalıştıran soyut roller yerine, her komutun ve doğrulamayı yapan assertion'ların net izlenebildiği yalın bir yapı kuruldu.

Canlı Depo Kontrolü ve Apt Seçimi (Election)

Resmi repo doğrudan sorgulandığında 7.0 LTS paketinin erişilebilir olduğu, 8.0 paketinin ise henüz Ubuntu 26.04 için derlenmediği teyit edildi:

$ curl -sI https://repo.zabbix.com/zabbix/7.0/ubuntu/dists/resolute/Release | head -1
HTTP/2 200 # 7.0 LTS paketi yayında

$ curl -sI https://repo.zabbix.com/zabbix/8.0/ubuntu/dists/resolute/Release | head -1
HTTP/2 404 # 8.0 ana sürümü henüz bu dağıtım için yok

Ubuntu Universe deposunda 7.0.22 sürümü yer alırken, resmi repo.zabbix.com üzerinde güncel 7.0.30 paketi bulunur. Paket yöneticisi (apt) yüksek sürüm numarasına sahip resmi depoyu seçer; ancak playbook bu varsayımla yetinmeyip apt-cache policy zabbix-agent2 çıktısını kontrol ederek paketin resmi repodan geldiğini ve 7.0 ailesinde kaldığını doğrular.

Kurulum Görevleri ve lock_timeout Ayrımı

İşlem sırası kritiktir: GPG anahtarı repo tanımından önce diske yazılmalıdır; aksi halde apt_repository anında tetiklediği güncellemede imzasız repo hatasıyla süreci kırar.

- name: Create the apt keyrings directory
  ansible.builtin.file:
    path: /etc/apt/keyrings
    state: directory
    mode: "0755"

- name: Install the Zabbix official repo signing key
  ansible.builtin.get_url:
    url: https://repo.zabbix.com/zabbix-official-repo.key
    dest: /etc/apt/keyrings/zabbix-official-repo.asc
    mode: "0644"

- name: Wait out the first-boot apt race before touching packages
  ansible.builtin.include_tasks: tasks/wait_for_apt.yml

- name: Add the pinned Zabbix apt repository
  ansible.builtin.apt_repository:
    repo: >-
      deb [signed-by=/etc/apt/keyrings/zabbix-official-repo.asc]
      https://repo.zabbix.com/zabbix/{{ zabbix_agent_version }}/ubuntu
      {{ ansible_facts['distribution_release'] }} main
    filename: zabbix-official-repo
    state: present

- name: Install Zabbix Agent 2
  ansible.builtin.apt:
    name: zabbix-agent2
    state: present
    lock_timeout: 1800

Saha Dersi (Bulgu #19): İlk pipeline denemesinde apt_repository adımına eklenen lock_timeout: 1800 parametresi görevi çökertti (Unsupported parameters for apt_repository module). Bu parametre yalnızca apt modülüne aittir. Kilit koruması wait_for_apt.yml geçidiyle çözüldüğü için parametre repo görevinden kaldırıldı, sadece paket kurulum adımında bırakıldı.

Yapılandırma ve Değişken Sözleşmesi

Yapılandırma Jinja2 şablonu üzerinden basılır:

# {{ ansible_managed }}
PidFile=/run/zabbix/zabbix_agent2.pid
LogFile=/var/log/zabbix/zabbix_agent2.log
Server={{ zabbix_agent_server }}
ListenPort={{ zabbix_agent_listenport }}
ServerActive={{ zabbix_agent_serveractive }}
Hostname={{ zabbix_agent_hostname }}
Include=/etc/zabbix/zabbix_agent2.d/plugins.d/*.conf

Bu şablonu besleyen vars/agent-layer.yml dosyası:

# Zabbix Agent 2 Parametreleri
zabbix_agent_version: "7.0"                # Resmi LTS deposu sürüm sabitlemesi
zabbix_agent_server: "192.168.122.10"      # Pasif kontrolleri sorgulayacak uç (ctrl-01)
zabbix_agent_serveractive: "192.168.122.10"# Aktif kontrollerin iletileceği uç
zabbix_agent_listenport: 10050             # Standart ajan dinleme portu
zabbix_agent_hostname: "{{ inventory_hostname }}" # Zabbix üzerindeki konak kimliği

Şablon güncellendiğinde Restart Zabbix Agent 2 handler'ı devreye girer. Playbook içindeki ansible.builtin.flush_handlers çağrısı, doğrulama testlerine geçmeden önce servisin yeniden başlatılmasını zorunlu kılar.

Beş Basamaklı Doğrulama ve zabbix-get

04_zabbix_agent.yml, sunucuya ihtiyaç duymadan ajanı 5 aşamalı bir test zincirinden geçirir:

1. Apt Seçim Sağlaması: apt policy çıktısından paketin repo.zabbix.com adresinden ve 7.0 ana sürümünden geldiği denetlenir.
2. Servis Durumu: service_facts ile ajanın running durumunda olduğu doğrulanır.
3. Soket Kontrolü: wait_for ile 127.0.0.1:10050 portunun açık olduğu görülür.
4. Yerel Metrik Testi: zabbix_agent2 -t agent.version komutu çalıştırılarak eklentilerin yüklendiği ve ajanın dahili metrik üretebildiği teyit edilir (rc=0).
5. Konfigürasyon Denetimi: Dağıtılan dosya slurp ile okunarak IP ve konak adı tanımları doğrulanır.

Uçtan uca son test kontrol makinesinden (ctrl-01) misafir ajana doğru tetiklenir:

# ctrl-01 üzerinden misafir ajanı sorgula:
zabbix_get -s 192.168.122.50 -k agent.version
# Çıktı: 7.0.30

---

Rsyslog Yönlendirme: QRadar Deseni

Sistem loglarının yalnızca yerel diskte tutulması felaket anında adli kanıtların yok olmasına neden olur. Ancak yaygın kullanılan *.* @@192.168.122.10:5514 gibi tek satırlık yönlendirme kuralları alıcı çöktüğü veya ağ kesildiği anda ya log akışını kilitler ya da veriyi sessizce düşürür.

Bu riski bertaraf etmek için disk destekli bir omfwd kuyruğu kurulmuştur:

action(type="omfwd"
  target="192.168.122.10"
  port="5514"
  protocol="tcp"
  queue.type="LinkedList"
  queue.filename="qradar_fwd"
  queue.maxDiskSpace="100m"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1")

Bu yapılandırmanın getirdiği davranış modeli:

• Loglar normal koşullarda bellekte (LinkedList) işlenir.
• Hedefe ulaşılamazsa bellek taşmasını engellemek için /var/spool/rsyslog altına geçici disk kuyruğu açılır.
• saveOnShutdown="on" sayesinde makine yeniden başlasa dahi iletilmemiş kuyruk silinmez.
• resumeRetryCount="-1" alıcı ayağa kalkana kadar iletim denemelerinin sonsuza dek sürmesini sağlar.

Parametreler yine vars/agent-layer.yml üzerinden yönetilir:

# Rsyslog Yönlendirme Parametreleri
rsyslog_receiver_host: "192.168.122.10" # SIEM / Alıcı IP (Laboratuvarda ctrl-01)
rsyslog_receiver_port: 5514             # Root yetkisi istemeyen socat test portu (Prodüksiyonda 514)
rsyslog_forward_protocol: "tcp"         # Paket kaybını önleyen TCP aktarımı
rsyslog_queue_maxdisk: "100m"           # Kuyruk diske taştığında ayrılacak üst sınır
rsyslog_test_tag: "phase3-test"         # Doğrulama aşamasında basılacak test log etiketi

12 Dakikalık Saha Kesinti Testi

ctrl-01 üzerindeki socat dinleyicisi SSH oturumu kapandığı için devre dışı kaldı. Bu esnada 05_rsyslog_forward.yml çalıştırıldı, ardından alıcı kapalıyken test logu üretildi:

# 1. Alıcı kapalı, port dinlenmiyor:
$ ss -tlnp | grep 5514
# (çıktı yok)

# 2. Misafir makinede log üretildi ve rsyslog servisi restart edilerek saveOnShutdown test edildi:
$ ssh ubuntu@192.168.122.50 'sudo systemctl restart rsyslog && ls -la /var/spool/rsyslog/'
-rw------- 1 syslog syslog 193147 Aug 28 09:45 qradar_fwd.00000001
-rw------- 1 syslog syslog    567 Aug 28 09:45 qradar_fwd.qi

# 3. Alıcı 12 dakika sonra arka planda ayağa kaldırıldı:
$ nohup socat -u TCP-LISTEN:5514,reuseaddr,fork OPEN:/tmp/qradar-stub.log,creat,append >/dev/null 2>&1 &

# 4. Yaklaşık 30 saniye sonra biriken tüm kuyruk hedefe ulaştı:
$ wc -l /tmp/qradar-stub.log
942 /tmp/qradar-stub.log

$ grep kuyruk /tmp/qradar-stub.log
<13>Aug 28 09:34:21 vm-test-01 phase3-test: kuyruk testi: alici kapaliyken gonderildi

Log satırındaki 09:34:21 zaman damgası mimarinin başarısını kanıtlar: Mesaj alıcı kapalıyken üretilmiş, iletim 12 dakika sonra gerçekleştiği halde satır orijinal üretim zamanıyla hedefe ulaşmıştır.

---

Stub Yükleyici Deseni ve Marker Sözleşmesi

Homelab ortamında Trend Micro Deep Security veya ManageEngine gibi lisanslı yazılımların ikili paketleri bulunmaz; ancak bu ajanları kuracak dağıtım hattının kendisi gerçektir. Bu ayrımı yönetmek için Marker Sözleşmesi (Marker Contract) kurgulanmıştır.

Ansible doğrudan ikili dosyanın içeriğiyle değil, kurulum tamamlandığında dosya sistemine bırakılan .installed belirteciyle el sıkışır:

#!/bin/sh
set -eu
INSTALL_DIR="{{ item.install_dir }}"
MARKER="{{ item.install_dir }}/.installed"

echo "[{{ item.name }}] yukleyici basliyor: surum {{ item.version }}..."

# -------------------------------------------------------------
# YUKLEME BLOKU (STUB)
# Lisans geldiginde YALNIZCA bu blok degistirilecek
echo "[{{ item.name }}] stub modu: ikili dosya yok, lisans kullanilmadi."
# -------------------------------------------------------------

mkdir -p "$INSTALL_DIR"
{
  echo "agent={{ item.name }}"
  echo "version={{ item.version }}"
  echo "mode={{ item.mode }}"
  echo "installed_at=$(date -Is)"
  echo "host=$(hostname -s)"
} > "$MARKER"

echo "[{{ item.name }}] marker yazildi: $MARKER"

Belirteç dosyası içindeki her alan belirli bir amaca hizmet eder:

• agent ve version: vars/agent-layer.yml içindeki tanımla eşleşmek zorundadır. Uyuşmazlık durumunda Ansible drift alarmı üretir.
• mode: Şu an stub değerine kilitlidir; prodüksiyona geçildiğinde real moduna çevrilir.
• installed_at: Adli bilişim açısından kurulum zamanını kanıtlar.
• host: Belirtecin başka bir sanal makineden kopyalanmadığını belgeler.

Drift Alarmı ve Lisans Geçişi

Kurulum adımı creates: "{{ item.install_dir }}/.installed" korumasıyla çalışır. Bu sayede belirteç mevcutsa görev işletilmez ve temiz ikinci çalıştırmada özet changed=0 döner.

Eğer değişken dosyasında sürüm 1.0.0-stub iken 1.1.0-stub yapılırsa:

1. Yükleyici betik şablonu yeni sürümle güncellenir.
2. creates koruması nedeniyle betik tekrar çalıştırılmaz, diskteki marker eski kalır.
3. Sonraki adımda marker içeriği okunup assertion çalıştırıldığında playbook hata verir ve süreci durdurur.

Bu yapı kontrolsüz güncellemeyi engelleyen bir güvenlik kilididir. Yeniden kurulum için marker'ın bilinçli olarak silinmesi gerekir:

ansible provisioned -m file -a "path=/opt/TrendMicro/.installed state=absent" -b
ansible-playbook playbooks/06_security_agents.yml

Lisanslar temin edildiğinde install.sh.j2 dosyasındaki indirme/kurulum bloğu güncellenecek, vars/agent-layer.yml içinde mode: real değerine geçilecek ve dağıtım hattı mimarisi bozulmadan gerçek ajanlar devreye alınacaktır.

---

Saha Doğrulama Adımları ve Terminal Sonuçları

Ajan katmanı sahada önce bağımsız adımlarla, ardından Semaphore UI dağıtım hattı üzerinden iki aşamada doğrulandı.

1. Zabbix Agent 2 Kurulumu (04_zabbix_agent.yml)

Ubuntu 26.04 cloud imajı /etc/apt/keyrings diziniyle geldiği ve apt install sonrası servis paket tetikleyicisi tarafından otomatik başlatıldığı için ilk çalıştırmada 5 değişiklik gerçekleşti:

$ ansible-playbook playbooks/04_zabbix_agent.yml
# ...
TASK [Receipt - agent on duty] ***************************************
ok: [vm-test-01] => {
  "msg": "zabbix-agent2 (repo 7.0) listening on port 10050; passive checks accepted from 192.168.122.10, active checks sent to 192.168.122.10 as host \"vm-test-01\". Self-test: agent.version [s|7.0.30]"
}

PLAY RECAP ***********************************************************
vm-test-01 : ok=19 changed=5 unreachable=0 failed=0

Aynı komut tekrar çalıştırıldığında handler tetiklenmedi ve idempotency kanıtlandı: ok=18 changed=0.

2. Rsyslog İletimi (05_rsyslog_forward.yml)

Paket sistemde kurulu geldiği için paket adımı ok döndü; spool dizin izin düzeltmesi, şablon kopyalama ve servis restart adımları değişimi oluşturdu:

$ ansible-playbook playbooks/05_rsyslog_forward.yml
# ...
PLAY RECAP ***********************************************************
vm-test-01 : ok=13 changed=3 unreachable=0 failed=0

İkinci çalıştırmada sistem tam kararlılığa ulaştı: ok=12 changed=0.

3. Güvenlik Ajanları Dağıtımı (06_security_agents.yml)

İki stub ajan sisteme dağıtıldı, marker dosyaları oluşturuldu ve doğrulandı:

$ ansible-playbook playbooks/06_security_agents.yml
# ...
PLAY RECAP ***********************************************************
vm-test-01 : ok=8 changed=3 unreachable=0 failed=0

# Sanal makinedeki marker çıktısı:
$ ssh ubuntu@192.168.122.50 'cat /opt/TrendMicro/.installed /opt/ManageEngine/.installed'
agent=trendmicro
version=1.0.0-stub
mode=stub
installed_at=2026-08-28T09:12:01+00:00
host=vm-test-01
agent=manageengine
version=1.0.0-stub
mode=stub
installed_at=2026-08-28T09:12:02+00:00
host=vm-test-01

Tekrarlanan çalıştırmada creates muhafazası devreye girdi: ok=8 changed=0.

---

Dağıtım Hattı Entegrasyonu (Pipeline)

Faz 4 kapsamında Semaphore UI üzerinden provizyon edilen vm-faz4-01 makinesinde tüm süreç otomatik tetiklendi. Süreç sırasında iki temel entegrasyon bulgusu çözüldü:

• Bulgu #18 (Run #31): Semaphore dinamik envanter kullandığından reponun group_vars tanımlarını doğrudan görmedi ve değişkenler tanımsız kaldı. Çözüm olarak tüm ajan yapılandırması vars/agent-layer.yml dosyasına toplandı ve playbook'lara vars_files ile bağlandı.
• Bulgu #19 (Run #36): apt_repository adımına verilen lock_timeout parametresi görevi çökertti. Hatalı parametre kaldırılarak dpkg kilitleri tasks/wait_for_apt.yml geçidine devredildi.
• Tam Başarı (Run #37): Hataların ardından pipeline baştan sona eksiksiz çalıştı:

# Run #37 pipeline özeti (vm-faz4-01)
PLAY RECAP *********************************************************************
localhost  : ok=16 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
vm-faz4-01 : ok=88 changed=11 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Makine üzerindeki changed=11 değeri, bağımsız çalıştırmalardaki değişimlerin toplamıdır ($5 + 3 + 3$). Otomasyonun terminalden manuel işletilmesi ile pipeline üzerinden tetiklenmesi arasında hiçbir davranış sapması yaşanmamıştır.

İlk Açılış Apt Kilitlenmesinin Çözümü (tasks/wait_for_apt.yml)

Yeni klonlanan bir sanal makine ilk açıldığında cloud-init paket güncellemelerini çalıştırırken unattended-upgrades de devreye girer. Bu aralıkta tetiklenen apt görevleri dpkg lock hatasıyla çöker.

Süreç adlarını (pgrep unattended-upgr) izlemek kalıcı servisler nedeniyle sonsuz döngüye yol açtığından, nihai çözüm doğrudan kilit dosyalarını izlemek oldu:

1. cloud-init status --wait komutuyla bulut başlatması beklenir.
2. /var/lib/dpkg/lock-frontend ve /var/lib/apt/lists/lock kilit dosyalarının boşa çıkması dinlenir.
3. Paket görevlerinde lock_timeout: 1800 kullanılarak yarış koşulu tamamen engellenir.

---

Faz 3 Kapanışı ve Sıradaki Adım

Ajan katmanı; harici koleksiyon bağımlılığı olmadan kurulan Zabbix Agent 2 omurgası, kesintiye dayanıklı disk destekli rsyslog kuyruğu ve lisans geçişine hazır drift korumalı marker mimarisiyle tamamlandı.

Süreç geride iki aktif mekanizma bıraktı:

• Makine içindeki logları merkezi kuyrukla toplayan oturum bağımsız dinleyici,
• Hem yerel hem de uzaktan tetiklenebilen 5 basamaklı servis sağlık denetimi.

Faz 3 tamamen kapanmıştır. Sıradaki çalışma Faz 4: Semaphore UI ile Uçtan Uca Otomatik Dağıtım:

• Form üzerinden parametrik VM provizyonu,
• Disklerin, LVM katmanının ve ajanların tek tıkla canlıya alınması,
• Dağıtım kapısı (Delivery Gate) ile provizyon doğrulama testleri.

---

GitHub Deposu