Set-OPS/docs/procedure-template-debian13-proxmox.md

# Procédure manuelle — VM Debian 13 prête à convertir en template Proxmox

## Objet du document

Ce document décrit le travail manuel à effectuer pour créer une VM Debian 13 propre dans Proxmox, jusqu’au moment où elle est prête à être convertie en modèle/template.

Le résultat attendu est une VM minimale, sobre, clonable, compatible avec cloud-init, prête à être prise en charge par Ansible et par le dépôt `Set-OPS`.

Ce document s’arrête juste avant la conversion finale en template Proxmox.

---

## 1. Objectif du modèle

Le modèle Debian 13 doit servir de base commune pour les futurs serveurs de Chezlepro Inc.

Objectifs :

- système Debian 13 minimal ;
- aucun environnement graphique ;
- SSH actif ;
- compte technique `ansible` disponible ;
- `ansible` autorisé à utiliser sudo sans mot de passe ;
- `qemu-guest-agent` installé ;
- `cloud-init` installé ;
- partitionnement simple et agrandissable ;
- aucune partition swap bloquant la croissance du disque ;
- aucune donnée propre à une VM finale ;
- aucune clé privée ;
- aucun secret ;
- prêt à être converti en template Proxmox.

---

## 2. Création de la VM dans Proxmox

### Paramètres généraux

Créer une nouvelle VM dans Proxmox avec des paramètres sobres.

Exemple :

```text
Nom de la VM : debian13-template
VMID         : 9000 ou autre ID réservé aux modèles
OS           : Debian 13
BIOS         : OVMF / UEFI
Machine      : q35
```

### Disque EFI Proxmox

Avec OVMF/UEFI, Proxmox crée un petit disque EFI, par exemple :

```text
efidisk0 : 4 Mo
```

Ce disque ne remplace pas la partition EFI de Debian.

Il sert à conserver les variables du firmware UEFI virtuel :

- ordre de démarrage ;
- entrées de boot ;
- variables UEFI ;
- paramètres liés à Secure Boot, si utilisé.

Il faut le garder.

---

## 3. Disque virtuel principal

### Type de disque

Pour une VM Linux moderne :

```text
Bus/Device      : SCSI
SCSI Controller : VirtIO SCSI single
IO thread       : activé si disponible
Cache           : Default / No cache
Discard         : selon stockage, seulement si pertinent
SSD emulation   : oui si le stockage est réellement SSD/NVMe
```

Même si le stockage réel est sur TrueNAS iSCSI, le disque présenté à la VM doit rester :

```text
SCSI via VirtIO SCSI single
```

Le choix SCSI ici concerne le bus virtuel vu par la VM, pas le protocole réel entre Proxmox et TrueNAS.

### Taille du disque

Pour le modèle de base :

```text
Disque : 16 Go
```

C’est suffisant pour une base Debian minimale.

Des clones pourront ensuite être agrandis avant le premier démarrage cloud-init.

---

## 4. Processeur

Pour un modèle portable entre plusieurs hôtes Proxmox :

```text
CPU Type : x86-64-v2-AES
Sockets  : 1
Cores    : 2
```

Éviter `host` pour un modèle générique, sauf si tous les nœuds Proxmox sont strictement homogènes et que la portabilité n’est pas une priorité.

---

## 5. Mémoire

Pour le modèle Debian 13 minimal :

```text
Mémoire : 2048 MiB
```

Le ballooning peut être activé, mais si la VM n’a pas de swap, éviter de descendre trop bas.

Réglage prudent :

```text
RAM max     : 2048 MiB
RAM minimum : 1536 MiB ou 2048 MiB
```

Pour un modèle simple, il est acceptable de laisser 2048 MiB fixe.

---

## 6. Carte graphique virtuelle

Pour un serveur Debian minimal :

```text
Display : Default / Standard VGA
```

Ne pas installer d’environnement graphique.

SPICE et VirtIO-GPU ne sont pas nécessaires pour un modèle serveur administré par SSH et Ansible.

---

## 7. Installation Debian 13

Démarrer la VM sur l’ISO Debian 13.

L’option `Graphical install` est acceptable : elle ne signifie pas qu’un environnement graphique sera installé. Elle ne concerne que l’interface de l’installateur.

---

## 8. Partitionnement

### Objectif

Le disque doit rester facile à agrandir après clonage.

Ne pas créer de partition swap à la fin du disque, car cela bloquerait l’agrandissement direct de la partition racine avec `growpart`.

### Partitionnement recommandé

Utiliser un partitionnement manuel :

```text
/dev/sda1   EFI System Partition   512 Mo   FAT32   /boot/efi
/dev/sda2   Linux root             reste    ext4    /
```

Ne pas créer :

```text
partition swap
LVM
/home séparé
/var séparé
```

### Pourquoi éviter LVM dans le modèle

Le stockage réel contient déjà plusieurs couches :

```text
TrueNAS ZFS
→ zvol iSCSI
→ Proxmox
→ disque virtuel
→ Debian
```

Ajouter LVM dans la VM complique le modèle sans bénéfice clair pour une base minimale.

### Pourquoi éviter la partition swap

Un exemple à éviter :

```text
/dev/sda1   EFI
/dev/sda2   /
/dev/sda3   swap
```

Si le disque est agrandi plus tard, l’espace libre sera après la swap. La partition `/` ne sera donc plus la dernière partition, ce qui complique ou empêche l’usage direct de :

```bash
growpart /dev/sda 2
resize2fs /dev/sda2
```

### Swap

Pour le modèle :

```text
Swap : aucun
```

L’avertissement de Debian au sujet de l’absence de swap peut être ignoré.

Si un clone a besoin de swap plus tard, utiliser plutôt :

- un swapfile ;
- ou un deuxième disque virtuel dédié au swap.

Exemple de swapfile futur :

```bash
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
```

---

## 9. Choix du noyau Debian

Si l’installateur demande quel noyau installer, choisir :

```text
linux-image-amd64
```

Ne pas choisir une version fixe du noyau sauf besoin très particulier.

Le méta-paquet `linux-image-amd64` suivra les mises à jour normales de Debian.

---

## 10. Image initrd

Si l’installateur demande le type d’image initrd, choisir :

```text
image générique : comporte tous les pilotes disponibles
```

C’est le meilleur choix pour un modèle Proxmox, car la VM doit rester portable même si certains paramètres virtuels changent plus tard.

---

## 11. Sélection des logiciels Debian

Dans l’écran de sélection des logiciels, cocher seulement :

```text
[x] serveur SSH
[x] utilitaires usuels du système
```

Laisser décoché :

```text
[ ] environnement de bureau Debian
[ ] GNOME
[ ] KDE Plasma
[ ] XFCE
[ ] LXDE
[ ] LXQt
[ ] MATE
[ ] serveur web
[ ] serveur d’impression
```

Le serveur web, les rôles applicatifs et les services métier seront installés plus tard par Ansible.

---

## 12. Premier démarrage après installation

Après l’installation, démarrer la VM et se connecter en console ou par SSH.

Passer root :

```bash
su -
```

ou, si sudo est déjà disponible :

```bash
sudo -i
```

---

## 13. Mise à jour du système

Exécuter :

```bash
apt update
apt full-upgrade -y
```

---

## 14. Paquets de base

Installer les paquets nécessaires au modèle :

```bash
apt install -y \
  sudo \
  qemu-guest-agent \
  cloud-init \
  cloud-guest-utils \
  curl \
  wget \
  ca-certificates \
  gnupg \
  vim \
  nano \
  bash-completion \
  htop \
  lsof \
  ncdu \
  tree \
  net-tools \
  iproute2 \
  dnsutils \
  chrony
```

Rôle des paquets principaux :

```text
sudo               : délégation administrative
qemu-guest-agent   : communication Proxmox ↔ VM
cloud-init         : personnalisation au premier boot du clone
cloud-guest-utils  : fournit notamment growpart
chrony             : synchronisation du temps
```

---

## 15. Activation du QEMU Guest Agent

Activer le service :

```bash
systemctl enable --now qemu-guest-agent
```

Vérifier :

```bash
systemctl status qemu-guest-agent --no-pager
```

Dans Proxmox, activer aussi :

```text
VM → Options → QEMU Guest Agent → Enabled
```

---

## 16. Configuration du compte ansible

### Ajouter le compte au groupe sudo

```bash
usermod -aG sudo ansible
```

### Autoriser sudo sans mot de passe

Créer le fichier dédié :

```bash
cat > /etc/sudoers.d/90-ansible <<'EOF'
ansible ALL=(ALL) NOPASSWD:ALL
EOF
```

Appliquer les permissions :

```bash
chmod 440 /etc/sudoers.d/90-ansible
```

Valider la syntaxe :

```bash
visudo -cf /etc/sudoers.d/90-ansible
```

Le résultat attendu est :

```text
/etc/sudoers.d/90-ansible: parsed OK
```

Tester depuis le compte `ansible` :

```bash
sudo -n true && echo OK
```

Résultat attendu :

```text
OK
```

---

## 17. SSH

### État transitoire

Pendant la construction du modèle, l’authentification par mot de passe peut rester active :

```text
PasswordAuthentication yes
```

C’est pratique tant que la clé SSH n’est pas encore injectée.

### État cible

Quand l’accès par clé SSH est confirmé, l’état cible sera :

```text
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
```

Ne pas désactiver le login par mot de passe avant d’avoir confirmé que l’accès par clé fonctionne.

### Tester une connexion SSH par mot de passe

Depuis un poste d’administration :

```bash
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no ansible@IP_DE_LA_VM
```

---

## 18. Cloud-init dans Debian

Vérifier que cloud-init est installé :

```bash
cloud-init --version
```

Vérifier le service :

```bash
systemctl status cloud-init --no-pager
```

Cloud-init servira à appliquer, au premier démarrage d’un clone :

- hostname ;
- utilisateur initial ;
- clé SSH publique ;
- IP ;
- passerelle ;
- DNS ;
- agrandissement de la partition racine si le disque a été étendu.

Cloud-init ne doit pas remplacer Ansible pour les rôles serveur complexes.

Séparation recommandée :

```text
cloud-init : identité initiale de la VM
Ansible    : configuration réelle du serveur
```

---

## 19. Ajout du CloudInit Drive dans Proxmox

Éteindre la VM :

```bash
shutdown -h now
```

Dans Proxmox :

```text
VM → Hardware → Add → CloudInit Drive
```

Ou en ligne de commande Proxmox :

```bash
qm set VMID --ide2 STORAGE:cloudinit
```

Exemple :

```bash
qm set 9000 --ide2 local-lvm:cloudinit
```

ou :

```bash
qm set 9000 --ide2 truenas-lvm:cloudinit
```

Le nom exact du stockage dépend de la configuration Proxmox.

---

## 20. Paramètres cloud-init dans Proxmox

Après ajout du CloudInit Drive, Proxmox permet de définir les paramètres cloud-init.

Exemple DHCP :

```bash
qm set 9000 --ciuser ansible
qm set 9000 --sshkeys ~/.ssh/id_ed25519.pub
qm set 9000 --ipconfig0 ip=dhcp
```

Exemple IP statique :

```bash
qm set 9000 --ciuser ansible
qm set 9000 --sshkeys ~/.ssh/id_ed25519.pub
qm set 9000 --ipconfig0 ip=192.168.11.150/24,gw=192.168.11.1
qm set 9000 --nameserver 192.168.11.1
```

Pour le modèle, éviter de lui donner une identité finale trop spécifique.

L’identité définitive doit plutôt être appliquée aux clones.

---

## 21. Vérifications avant nettoyage

Redémarrer la VM une dernière fois si nécessaire, puis vérifier :

```bash
lsblk
df -h
swapon --show
ip a
hostnamectl
timedatectl
systemctl status ssh --no-pager
systemctl status qemu-guest-agent --no-pager
cloud-init --version
```

État attendu :

```text
/boot/efi présent
/ sur ext4
aucun swap actif
qemu-guest-agent actif
ssh actif
cloud-init installé
compte ansible fonctionnel
sudo NOPASSWD fonctionnel pour ansible
```

---

## 22. Nettoyage avant conversion en template

Avant de convertir la VM en modèle, nettoyer l’état propre à cette installation.

Exécuter dans la VM :

```bash
sudo cloud-init clean --logs
sudo apt clean
```

Nettoyer l’identifiant machine :

```bash
sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
```

Optionnel : vider les journaux persistants si présents :

```bash
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s
```

Optionnel : supprimer l’historique shell du compte courant :

```bash
history -c
```

Puis éteindre :

```bash
sudo shutdown -h now
```

---

## 23. Point d’arrêt : VM prête à convertir

À ce stade, la VM doit être arrêtée.

Elle est prête à être convertie en template Proxmox.

État attendu côté Proxmox :

```text
VM arrêtée
BIOS OVMF / UEFI
Machine q35
EFI Disk présent
Disque principal SCSI / VirtIO SCSI single
CloudInit Drive présent
QEMU Guest Agent activé dans les options
CPU x86-64-v2-AES
RAM 2048 MiB
Aucun environnement graphique
```

État attendu côté Debian :

```text
Debian 13 minimal
SSH installé
qemu-guest-agent installé
cloud-init installé
cloud-guest-utils installé
sudo installé
compte ansible présent
sudo NOPASSWD pour ansible
partition EFI 512 Mo
partition / ext4
aucune partition swap
aucun LVM
machine-id nettoyé
cloud-init nettoyé
apt cache nettoyé
VM éteinte
```

---

## 24. Conversion en template Proxmox

Cette commande n’est exécutée qu’après validation finale :

```bash
qm template VMID
```

Exemple :

```bash
qm template 9000
```

À partir de là, le modèle peut être cloné.

---

## 25. Flux normal après conversion

Après conversion du modèle :

```text
1. Cloner le template.
2. Agrandir le disque si nécessaire.
3. Définir hostname, IP, DNS et clé SSH via cloud-init.
4. Démarrer la VM.
5. Laisser cloud-init appliquer l’identité initiale.
6. Se connecter en SSH.
7. Appliquer les rôles Ansible depuis Set-OPS.
```

Exemple :

```bash
qm clone 9000 101 --name web-01 --full true
qm resize 101 scsi0 32G
qm set 101 --ciuser ansible
qm set 101 --sshkeys ~/.ssh/id_ed25519.pub
qm set 101 --ipconfig0 ip=192.168.11.101/24,gw=192.168.11.1
qm set 101 --nameserver 192.168.11.1
qm start 101
```

Puis :

```bash
ssh ansible@192.168.11.101
```

Ensuite seulement :

```bash
ansible-playbook -i inventories/production/hosts.yml playbooks/baseline.yml
```

---

## 26. Résumé court

Le modèle idéal est simple :

```text
Debian 13 minimal
UEFI / OVMF
q35
SCSI / VirtIO SCSI single
16 Go
2 Go RAM
2 cores
partition EFI 512 Mo
partition / ext4
pas de LVM
pas de swap
SSH
sudo
qemu-guest-agent
cloud-init
cloud-guest-utils
compte ansible
sudo NOPASSWD pour ansible
cloud-init clean
machine-id vidé
VM éteinte
```

La philosophie :

```text
Proxmox crée la VM.
Cloud-init donne son identité au clone.
Ansible configure le vrai serveur.
Set-OPS documente et automatise l’ensemble.
```