Blueforce-Linux/docs/_TEMPLATE.md
emirhanmamak-blueforce ef102b9657 feat(field-os): provisioning layer, real ISO build, offline contracts
Adds the Blueforce Field OS provisioning stack on top of the existing fleet
architecture, without rewriting the working systems (installer, diagnostics,
Ansible, WireGuard/SSH/xRDP/RustDesk, Docker policies, monitoring, Docusaurus).

ISO build (the previous builder was a skeleton that produced no medium):
- boot layout is read from the base ISO at build time via
  `xorriso -report_el_torito as_mkisofs` and rebuilt with `-as mkisofs`;
  `-boot_image any replay` cannot work on Ubuntu live ISOs because the GRUB2
  MBR lives in the source image's first 16 sectors and the EFI system partition
  is an appended partition, neither of which is a file in the ISO9660 tree
- preflight now asserts El Torito boot metadata positively: xorriso exits 0 on
  a non-ISO input, which previously let an arbitrary file pass --check
- artifact produced and verified: dist/Blueforce-Field-OS-1.0.0-amd64.iso,
  6 481 917 952 bytes, SHA256 cb0cc56f...d431296, BIOS+UEFI entries preserved,
  /autoinstall.yaml at the media root, casper/minimal.squashfs byte-identical
  to the base
- recorded baseline deviation: the verified medium on the build host is the
  Desktop flavour, so the manifest carries a baseline_deviation block instead
  of hiding it; Server remains one flag away

Offline and identity:
- offline APT contract with concrete package requirements, pin format and an
  audit table; builds fail closed while pins are UNPINNED
- autoinstall keeps interactive-sections: [storage]: the operator confirms the
  target disk, and no automatic wipe is ever performed
- firstboot terminal wizard for the 8-digit dealer id, three-state lifecycle
  (PROVISIONED_OFFLINE -> ENROLLED -> READY) with fail-closed gates, so a
  missing internet link or WireGuard handshake cannot fail provisioning but can
  never produce a false READY

Fleet and migration:
- five read-only Ansible playbooks for Field OS version, provisioning,
  enrollment, remote channels and offline readiness, all wave-scoped with a
  separate production override
- Windows pre-migration inventory and data export extended to the full brief
  scope, read-only, never collecting credentials

Tests: tests/run-all.sh -> 8/8 pass, exit 0. Boot acceptance (UEFI, Legacy
BIOS, Secure Boot), air-gapped install, real enrollment endpoint and Windows
rollback remain LAB work and are listed in IMPLEMENTATION-REPORT.md.
2026-09-16 11:14:42 +03:00

123 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# <DOKÜMAN BAŞLIĞI>
> Kısa özet: bu doküman neyi kapsar, kimin içindir, hangi kararı verir. (2–3 cümle)
- Dosya: `docs/NN-KONU.md`
- İlgili kararlar: `24-DECISION-LOG.md#<başlık>`
- Durum: [ ] Taslak / [ ] İncelemede / [ ] Onaylı
**Şablon kuralları (bu repoda zorunlu):**
- Bölümler `## 1.` … `## 13.` sırasıyla ve atlanmadan doldurulur; ek bölümler yalnız `## Ek: <ad>` başlığıyla açılır (numaralı bölüm eklenmez).
- Her numaralı dokümanda **en az bir Mermaid** diyagram bloğu bulunur (akış, katman, durum veya kapı diyagramı).
- Dil: açıklamalar Türkçe; komut, dosya, servis, paket ve terim adları İngilizce kalır.
- Her teknik iddia kaynaklıdır: KARAR bloklarında resmi kaynak URL + sürüm + doğrulama tarihi yazılır; doğrulanamayan davranış "LAB gerekli" etiketiyle açık bırakılır.
- Dosya numarası bir kez verilir ve yeniden kullanılmaz; kararlar (`24-DECISION-LOG.md`) **append-only**dir, mevcut karar silinmez/yeniden numaralanmaz.
- Secret yasak: örneklerde yer tutucu kullanılır (parola, private key, token, cihaz-spesifik kimlik yazılmaz).
- Bu dosya (`_TEMPLATE.md`) numaralı değildir ve `docs-site`'a alınmaz.
---
## 1. Amaç
Bu dokümanın neden var olduğu, hangi sorunu çözdüğü.
## 2. Kapsam
Kapsam içi ve kapsam dışı maddeler:
- Kapsam içi: ...
- Kapsam dışı: ...
## 3. Kararlar
Her teknik karar için aşağıdaki karar bloğunu kullan:
```text
KARAR: <alınan karar, tek cümle>
GEREKÇE: <neden bu karar — teknik dayanak, 1–3 cümle>
ALTERNATİF: <değerlendirilen en güçlü alternatif + neden elendi>
RİSK: <kararın getirdiği en büyük risk + azaltma notu>
MALİYET: <Ücretsiz / Ücretli (işaretli) + not>
LİSANS: <lisans adı + kaynak URL + sürüm + doğrulama tarihi>
```
Örnek:
```text
KARAR: Filo yönetiminde Ansible + Semaphore UI Community kullanılır.
GEREKÇE: Agent gerektirmez, SSH tabanlıdır, 700 cihaz ölçeğinde yeterlidir.
ALTERNATİF: SaltStack — daha karmaşık kurulum nedeniyle elendi.
RİSK: Playbook hatası filoya yayılabilir; önce LAB(2) grubunda çalıştırılır.
MALİYET: Ücretsiz (self-hosted).
LİSANS: Semaphore Community (kaynak doğrulanacak) — URL + sürüm + tarih eklenecek.
```
## 4. Neden Bu Karar?
Kararların arkasındaki teknik ve operasyonel gerekçeler. Sadelik kuralı burada denetlenir: Kubernetes, microservice, gereksiz agent/DB/cloud öneriliyorsa neden reddedildiği yazılır.
## 5. Alternatifler
| Alternatif | Artı | Eksi | Sonuç |
|---|---|---|---|
| ... | ... | ... | Elendi / Yedek |
## 6. Avantajlar
- ...
## 7. Dezavantajlar
- ...
## 8. Riskler
| Risk | Olasılık | Etki | Azaltma |
|---|---|---|---|
| ... | Düşük/Orta/Yüksek | ... | ... |
## 9. Uygulama Planı
Numaralı adımlar; komutlar İngilizce orijinal adıyla, açıklamalar Türkçe:
1. ...
2. ...
```bash
# örnek komut bloğu
hostnamectl set-hostname bf-12010193
```
## 10. Test Planı
| Test | Beklenen sonuç | Ortam |
|---|---|---|
| ... | ... | LAB(2) |
## 11. Rollback
Başarısızlıkta önceki duruma dönüş adımları:
1. ...
2. ...
## 12. Kontrol Listesi
- [ ] ...
- [ ] ...
## 13. Açık Sorular
- [ ] ... (sahibi + tarih ile)
---
## Ek: Mermaid Örneği
```mermaid
flowchart LR
Saha["bf-12010193<br/>(saha PC'si)"] -->|WireGuard| Merkez["Merkez sunucu"]
Merkez --> Ansible["Ansible/Semaphore"]
Merkez --> Monitor["Monitoring"]
```