783 lines
14 KiB
Markdown
783 lines
14 KiB
Markdown
# 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.
|
||
```
|