system_update/docs/design/tache2/60-profils-os-machine.md

60 — Profils OS, type machine, overrides et proxy APT

Axe A + livrables §4.5/§4.6. Tranche §3.2 (structure profils OS) et §3.3 (profils machine). Couvre la grille §7 (« Profils OS et type de machine »).

---

1. Deux dimensions distinctes

• os_family : debian | ubuntu | proxmox | raspbian | unknown (quelle distro / quel jeu de dépôts et de commandes).
• machine_kind : physical | vm | proxmox_host | lxc | raspberry_pi | workstation | unknown (quel matériel / quels scripts pertinents : firmware, drivers, guest tools…).

Les deux sont orthogonaux : une Debian peut être physique, VM ou LXC ; un Raspberry Pi OS implique presque toujours raspberry_pi. Choisis manuellement à l'ajout, corrigeables par machine_probe. Stockés dans machines.os_family / machine_kind / virtualization / hardware_profile (tache1.9.md §5).

---

2. Arborescence des templates et héritage (décision §3.2)

Convention de dossier + fallback base. Le moteur de rendu choisit le template le plus spécifique disponible, sinon retombe sur le profil générique.

templates/
├── apt/                       # profil "base" (Debian/Ubuntu générique — jalon 1)
│   ├── update-analyze.sh.tpl
│   ├── upgrade.sh.tpl
│   ├── full-upgrade.sh.tpl
│   ├── autoremove.sh.tpl
│   ├── clean.sh.tpl
│   ├── reboot-check.sh.tpl
│   └── reboot.sh.tpl
├── proxmox/                   # overrides Proxmox (dépôts PVE, kernel, Ceph)
│   ├── update-analyze.sh.tpl
│   └── full-upgrade.sh.tpl
├── raspbian/                  # overrides Raspberry Pi OS (firmware, espace disque)
│   ├── update-analyze.sh.tpl
│   └── full-upgrade.sh.tpl
├── docker/
│   └── *.sh.tpl
└── custom/
    └── *.sh.tpl

Résolution (pseudo-code backend) :

resolveTemplate(action, osFamily):
  candidate = templates/<osFamily>/<action>.sh.tpl
  if exists(candidate): return candidate
  return templates/apt/<action>.sh.tpl          # fallback base

Pourquoi pas un héritage par fragments/includes Mustache ? Plus simple à auditer en Git (un fichier = un script complet, lisible et testable). Inconvénient : duplication partielle entre profils — accepté au MVP (peu de profils). Alternative notée en §3.2 de 90-questions-investigation.md.

Non-régression jalon 1 : Debian/Ubuntu n'ont pas de dossier dédié ⇒ ils tombent sur templates/apt/* (comportement actuel inchangé). Le mécanisme de résolution est additif.

---

3. Overrides par machine

Au-delà du profil OS, chaque machine peut surcharger :

• aptProxyMode / aptProxyUrl (déjà présent au jalon 1) ;
• des variables de contexte (composeRoots, inactivityTimeout, etc.) ;
• l'activation de templates (templates activables côté formulaire) ;
• des presets de variables custom (script_variables_presets scope machine).

Priorité de résolution des variables : override machine > défaut profil OS > défaut global. Aucun override ne peut introduire un secret dans un template (les secrets restent côté machine_credentials, injectés uniquement via runScriptSudo stdin).

---

4. Spécificités par profil OS

Debian

• apt-get update + dist-upgrade standard.
• Avant firmware/drivers propriétaires : vérifier contrib, non-free, non-free-firmware dans les sources (lecture seule, template check-components). Proposition uniquement.
• Source : https://www.debian.org/releases/bookworm/amd64/ch02s02.en.html

Ubuntu

• Idem Debian + ubuntu-drivers devices (lecture) pour proposer des drivers (NVIDIA/GPU), surtout sur machine_kind physique/workstation/gpu. Jamais installé par défaut.

Proxmox (profil dédié, jamais Debian générique)

• Contrôler les dépôts PVE : pve-no-subscription vs enterprise (sinon apt update échoue sur le dépôt entreprise sans abonnement).
• Meta-package proxmox-ve, kernel PVE, Ceph éventuel.
• apt-get update puis apt-get dist-upgrade.
• Source : https://pve.proxmox.com/wiki/System_Software_Updates

Raspberry Pi OS (profil dédié)

• Attention firmware/kernel (rpi-update non utilisé par défaut — risqué).
• Vérifier l'espace disque avant upgrade (carte SD souvent petite).
• Utiliser full-upgrade.
• Source : https://www.raspberrypi.com/documentation/usage/terminal/

---

5. Influence du type machine sur les scripts proposés

machine_kind	Scripts pertinents	À éviter
physical	détection hardware, firmware (fwupd), SMART/disques, sensors, drivers GPU, benchmark	guest tools
vm	guest tools (qemu-guest-agent ou open-vm-tools)	drivers GPU/firmware (sauf passthrough)
proxmox_host	profil Proxmox dédié (dépôts PVE, kernel, Ceph)	traitement Debian générique
lxc	minimal (pas de kernel/firmware propre au conteneur)	firmware, drivers, reboot kernel
raspberry_pi	profil RPi (firmware/kernel prudent, espace disque)	drivers GPU desktop
workstation / GPU server	drivers GPU (ubuntu-drivers/nvidia), benchmark	—

Les scripts hardware/drivers/benchmark ne sont jamais installés par défaut et exigent validation explicite (couverture §7).

---

6. Détection / correction : machine_probe (décision §3.3)

Action non destructive (lecture seule), proposée à l'ajout et relançable. Sources lues :

#!/bin/sh
export LC_ALL=C
echo "===SU:PROBE_OS==="
cat /etc/os-release 2>/dev/null
echo "===SU:PROBE_ARCH==="
uname -m
dpkg --print-architecture 2>/dev/null
echo "===SU:PROBE_VIRT==="
systemd-detect-virt 2>/dev/null || echo "none"
echo "===SU:PROBE_PROXMOX==="
[ -d /etc/pve ] && echo "PROXMOX=1" || echo "PROXMOX=0"
echo "===SU:PROBE_RPI==="
grep -qi raspberry /proc/cpuinfo 2>/dev/null && echo "RPI=1" || echo "RPI=0"
echo "===SU:PROBE_GPU==="
command -v lspci >/dev/null 2>&1 && lspci 2>/dev/null | grep -Ei 'vga|3d|display' || echo "no-lspci"
echo "===SU:PROBE_NET==="
ip -o -4 addr show 2>/dev/null | awk '{print $2, $4}'
echo "===SU:EXIT=0==="

Le backend propose une correction de os_family/machine_kind/virtualization/interface primaire, jamais appliquée automatiquement sans validation utilisateur (règle de correction : l'opérateur garde le dernier mot). Résultats persistés dans machine_hardware + colonnes machines.

MVP retenu : choix manuel à l'ajout (Debian/Ubuntu/Proxmox VE/Raspberry Pi OS/autre Linux ; VM/physique/Proxmox/LXC/RPi/GPU-workstation) + machine_probe pour proposer des corrections. Alternative (détection 100 % automatique) jugée trop fragile (cas limites : conteneurs imbriqués, distros dérivées) — voir 90-questions-investigation.md Q3.

---

7. Proxy APT (apt-cacher-ng) — trois modes

AptProxyMode = "direct" | "runtime" | "persistent" (le persistent est l'ajout tâche 2).

Mode	Mécanisme	Quand
direct	aucun proxy	défaut
runtime	export http_proxy/https_proxy dans le script (sections Mustache {{#aptProxy}}) — comportement jalon 1, conservé	proxy temporaire pour une exécution
persistent	écrire Acquire::http::Proxy "<url>"; dans /etc/apt/apt.conf.d/01proxy (action dédiée, idempotente, sauvegarde de l'existant)	proxy permanent de la machine

Le mode persistent est une action explicite (écriture sur disque) avec preview ; il n'est pas appliqué silencieusement. runtime reste injecté au rendu comme aujourd'hui.