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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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

Ne pas créer :

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 :

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 :

/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 :

growpart /dev/sda 2
resize2fs /dev/sda2

Swap

Pour le modèle :

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 :

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 :

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 :

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 :

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

Laisser décoché :

[ ] 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 :

su -

ou, si sudo est déjà disponible :

sudo -i

---

13. Mise à jour du système

Exécuter :

apt update
apt full-upgrade -y

---

14. Paquets de base

Installer les paquets nécessaires au modèle :

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 :

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 :

systemctl enable --now qemu-guest-agent

Vérifier :

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

Dans Proxmox, activer aussi :

VM → Options → QEMU Guest Agent → Enabled

---

16. Configuration du compte ansible

Ajouter le compte au groupe sudo

usermod -aG sudo ansible

Autoriser sudo sans mot de passe

Créer le fichier dédié :

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

Appliquer les permissions :

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

Valider la syntaxe :

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

Le résultat attendu est :

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

Tester depuis le compte ansible :

sudo -n true && echo OK

Résultat attendu :

OK

---

17. SSH

État transitoire

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

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 :

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 :

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

---

18. Cloud-init dans Debian

Vérifier que cloud-init est installé :

cloud-init --version

Vérifier le service :

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 :

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

---

19. Ajout du CloudInit Drive dans Proxmox

Éteindre la VM :

shutdown -h now

Dans Proxmox :

VM → Hardware → Add → CloudInit Drive

Ou en ligne de commande Proxmox :

qm set VMID --ide2 STORAGE:cloudinit

Exemple :

qm set 9000 --ide2 local-lvm:cloudinit

ou :

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 :

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

Exemple IP statique :

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 :

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 :

/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 :

sudo cloud-init clean --logs
sudo apt clean

Nettoyer l’identifiant machine :

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 :

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

Optionnel : supprimer l’historique shell du compte courant :

history -c

Puis éteindre :

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 :

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 :

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 :

qm template VMID

Exemple :

qm template 9000

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

---

25. Flux normal après conversion

Après conversion du modèle :

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 :

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 :

ssh ansible@192.168.11.101

Ensuite seulement :

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

---

26. Résumé court

Le modèle idéal est simple :

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 :

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