Afficher/cacher Sommaire
- Description matériel Lenovo ThinkCentre M700 Tiny et mise à jour BIOS
- Comment installer Proxmox VE 7.0 et créer sa première VM ?
Proxmox
Image proxmox-ve_7.2-1.iso
Installation à partir d’une clé USB avec l’image proxmox-ve_7.2-1.iso
Réseau /etc/network/interfaces
auto lo
iface lo inet loopback
# Ensuite l'interface bridge "vmbr0" qui se configure par DHCP
auto vmbr0
iface vmbr0 inet static
address 192.168.0.145
netmask 255.255.255.0
gateway 192.168.0.254
# Liste des interfaces qui participent au bridge
# ATTENTION :
# Il faut mettre l'interface dont la MAC est la plus petite d'abord !
# Sinon, cela peut perturber les outils de surveillance du réseau.
# bridge_ports eno1 eth0 eth1 eth2
bridge_ports eno1
# Je désactive le Spanning tree
bridge_stp off
# Temps en secondes entre "learning state" et "forwarding state"
bridge_fd 2
# Temps maximum en secondes où le script de lancement du bridge
# attendra lors du démarrage que le bridge passe en mode "forwarding
# state" pour passer la main et laisser les autres services démarrer.
bridge_maxwait 0
iface vmbr0 inet6 static
address 2a01:e34:eebf:5661::1
netmask 64
gateway fe80::8e97:eaff:fe39:66d6
DNS /etc/resolv.conf
search rnmkcy.eu
nameserver 1.1.1.1
Accès via SSH
SSH activé avec autorisation connexion root
Accès SSH : ssh root@192.168.0.145
Créé un second compte administrateur sur PROXMOX
Créé s’il n’existe pas déjà l’utilisateur leno sur votre serveur
adduser leno
Cette commande permet d’ajouter l’utilisateur à la base d’authentification proxmox
pveum useradd leno@pam
Cette commande change le mot de passe de l’utilisateur attention elle changera aussi le mot de passe du compte associé sur votre serveur. Vous pouvez ne pas l’utiliser si vous avez en tête votre mot de passe.
pveum passwd leno@pam
Cette commande ajoute les droits Administrateurs sur toute l’interface à l’utilisateur qu’on vient de créer.
pveum aclmod / -user leno@pam -roles Administrator
Cette commande désactive le compte administrateur root
pveum usermod root@pam -enable 0
Si lors d’une manipulation vous avez un souci étrange et qu’il réclame le compte root (ajout de certificat par exemple) vous pouvez le réactiver avec l’interface web ou avec la commande.
pveum usermod root@pam -enable 1
Connexion SSH PC1 –> Lenovo
connexion avec clé
sur l'ordinateur de bureau
Générer une paire de clé curve25519-sha256 (ECDH avec Curve25519 et SHA2) pour une liaison SSH avec le serveur.
ssh-keygen -t ed25519 -o -a 100 -f ~/.ssh/lenovo-ed25519
Envoyer les clés publiques sur le serveur KVM
ssh-copy-id -i ~/.ssh/lenovo-ed25519.pub leno@192.168.0.145
sur le serveur KVM
On se connecte
ssh root@192.168.0.145
Modifier la configuration serveur SSH
nano /etc/ssh/sshd_config
Modifier
PermitRootLogin no
Port = 55145
PasswordAuthentication no
ChallengeResponseAuthentication yes
Relancer le serveur
systemctl restart sshd
Test connexion
ssh -p 55145 -i ~/.ssh/lenovo-ed25519 leno@192.168.0.145
Mises à jour proxmox
On se connecte en utilisateur leno sur proxmox
ssh -p 55145 -i ~/.ssh/lenovo-ed25519 leno@192.168.0.145
Accés root par commande su
On désactive les dépôts entreprise dans le fichier /etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve bullseye pve-enterprise
Lancer les mises à jour : apt update && apt upgrade
Installer sudo : apt install sudo
Donner les droits root à leno : echo "leno ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
nginx
Installer nginx : sudo apt install nginx
Redémarrer la machine : systemctl reboot
Motd
On se connecte en utilisateur leno sur proxmox via SSH
Effacer et créer motd
sudo rm /etc/motd && sudo nano /etc/motd
___
| _ \ _ _ ___ __ __ _ __ ___ __ __
| _/| '_|/ _ \\ \ /| ' \ / _ \\ \ /
|_| |_| \___//_\_\|_|_|_|\___//_\_\
_
_ __ __ __ ___ _ _ _ _ _ __ | |__ __ _ _ ___ _ _
| '_ \\ V // -_) _ | '_|| ' \ | ' \ | / // _|| || | _ / -_)| || |
| .__/ \_/ \___|(_)|_| |_||_||_|_|_||_\_\\__| \_, |(_)\___| \_,_|
|_| |__/
_ ___ ___ _ __ ___ __ _ _ _ ___
/ |/ _ \|_ ) / | / / ( _ ) / \ / || | | | __|
| |\_, / / / _ | |/ _ \/ _ \ _| () |_ | ||_ _||__ \
|_| /_/ /___|(_)|_|\___/\___/(_)\__/(_)|_| |_| |___/
Script ssh_rc_bash
ATTENTION!!! Les scripts sur connexion peuvent poser des problèmes pour des appels externes autres que ssh
Prérequis : sudo apt install jq figlet
Installer le bash
wget https://static.xoyaz.xyz/files/ssh_rc_bash
chmod +x ssh_rc_bash # rendre le bash exécutable
./ssh_rc_bash # exécution
Domaine et certificat
On se connecte en utilisateur leno sur proxmox
ssh -p 55145 -i ~/.ssh/lenovo-ed25519 leno@192.168.0.145
DNS OVH rnmkcy.eu
Zone DNS accessible UNIQUEMENT en IPV6
$TTL 3600
@ IN SOA dns110.ovh.net. tech.ovh.net. (2022010102 86400 3600 3600000 300)
IN NS dns110.ovh.net.
IN NS ns110.ovh.net.
IN AAAA 2a01:e0a:2de:2c71::1
IN CAA 128 issue "letsencrypt.org"
* IN AAAA 2a01:e0a:2de:2c71::1
Certificats Let’s Encrypt
Installation gestionnaire des certificats Let’s Encrypt
cd ~
sudo apt install socat git # prérequis
git clone https://github.com/acmesh-official/acme.sh.git
cd acme.sh
./acme.sh --install
Se déconnecter puis se reconnecter utilisateur
Les clés OVH API
export OVH_AK="xxxxxxxxxxxxxxxxxx"
export OVH_AS="yyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Génération des certificats
acme.sh --dns dns_ovh --server letsencrypt --issue --keylength ec-384 -d 'rnmkcy.eu' -d '*.rnmkcy.eu'
[...]
[Sat 08 Oct 2022 02:57:23 PM CEST] Please open this link to do authentication: https://www.ovh.com/auth/sso/api?credentialToken=93870afdea0997a4f51117d099655cb0c9c7416f609f802ad1fd8cb6b01a6df9
[...]
Après authentification relancer la commande
Résultat de l’installation
[Sat 08 Oct 2022 02:59:21 PM CEST] Your cert is in: /home/leno/.acme.sh/rnmkcy.eu_ecc/rnmkcy.eu.cer
[Sat 08 Oct 2022 02:59:21 PM CEST] Your cert key is in: /home/leno/.acme.sh/rnmkcy.eu_ecc/rnmkcy.eu.key
[Sat 08 Oct 2022 02:59:21 PM CEST] The intermediate CA cert is in: /home/leno/.acme.sh/rnmkcy.eu_ecc/ca.cer
[Sat 08 Oct 2022 02:59:21 PM CEST] And the full chain certs is there: /home/leno/.acme.sh/rnmkcy.eu_ecc/fullchain.cer
Installation des certificats
sudo mkdir -p /etc/ssl/private/
sudo chown $USER -R /etc/ssl/private/
acme.sh --ecc --install-cert -d 'rnmkcy.eu' -d '*.rnmkcy.eu' --key-file /etc/ssl/private/rnmkcy.eu-key.pem --fullchain-file /etc/ssl/private/rnmkcy.eu-fullchain.pem --reloadcmd 'sudo systemctl reload nginx.service'
Résultat
[Sat 08 Oct 2022 03:01:25 PM CEST] Installing key to: /etc/ssl/private/rnmkcy.eu-key.pem
[Sat 08 Oct 2022 03:01:25 PM CEST] Installing full chain to: /etc/ssl/private/rnmkcy.eu-fullchain.pem
[Sat 08 Oct 2022 03:01:25 PM CEST] Run reload cmd: sudo systemctl reload nginx.service
[Sat 08 Oct 2022 03:01:26 PM CEST] Reload success
Supprimer ` –reloadcmd ‘sudo systemctl reload nginx.service’` à la ligne précédente si Nginx n’est pas installé
Renouvellement auto des certificats
2 méthodes :
- crontab si le serveur est en ligne 24/24h
- systemd timer utilisateur dans le cas contraire
1 - crontab
Editer le crontab, supprimer la ligne existante et ajouter ce qui suit
crontab -e
35 0 * * * "/home/leno/.acme.sh"/acme.sh --cron --home "/home/leno/.acme.sh" --renew-hook "/home/leno/.acme.sh/acme.sh --ecc --install-cert -d 'rnmkcy.eu' -d '*.rnmkcy.eu' --key-file /etc/ssl/private/rnmkcy.eu-key.pem --fullchain-file /etc/ssl/private/rnmkcy.eu-fullchain.pem --reloadcmd 'sudo systemctl reload nginx.service'" > /dev/null
2 - systemd timer utilisateur
Le serveur debsrv n’est pas sous tension 24h/24h. Le renouvellement des certificats doit être testé au démarrage du serveur et une fois par jour. Pour cela on utulise un ervice et un timer systemd utilisateur.
Le bash de renouvellement ~/renouvcertif.sh
"/home/leno/.acme.sh"/acme.sh --cron --home "/home/leno/.acme.sh" --renew-hook "/home/leno/.acme.sh/acme.sh --ecc --install-cert -d 'rnmkcy.eu' -d '*.rnmkcy.eu' --key-file /etc/ssl/private/rnmkcy.eu-key.pem --fullchain-file /etc/ssl/private/rnmkcy.eu-fullchain.pem --reloadcmd 'sudo systemctl reload nginx.service'"
Droits en exécution
chmod +x ~/renouvcertif.sh
Tester le bash
./renouvcertif.sh
Le fonctionnement de systemd impose cependant d’avoir deux fichiers : service, qui contient la définition du programme et timer, qui dit “quand” le lancer et ils doivent porter le même nom
Créer le dossier systemd utilisateur
mkdir -p ~/.config/systemd/user
Si vous gérez déjà vos services via systemd, vous avez déjà utilisé des “unit” systemd de type “service”.
Ces “unit” permettent de définir un process et son mode d’éxécution.
Pour implémenter un “timer” sous systemd, il va nous falloir un fichier “service”.
Pour notre tâche à planifier, nous allons avoir au final 3 fichiers :
- Le fichier “service” qui va dire quel script exécuter
- Le fichier “timer” qui va indiquer quand il doit être exécuté.
- Le script à exécuter
A noter que par convention, les fichiers service et timer doivent avoir le même nom
Nous devons exécuter ,une fois par jour , un script de renouvellement certificat /home/leno/renouvcertif sur un ordinateur qui n’est pas sous tension 24/24h.
Pour le fichier service ~/.config/systemd/user/renouvcertif.service
, une base simple
[Unit]
Description=renouvellement certificat
[Service]
Type=simple
ExecStart=/bin/bash /home/leno/renouvcertif.sh
StandardError=journal
Type=oneshot
Je fournis une description à mon service, indique que c’est un process de type simple, le chemin vers mon script et je rajoute que le flux d’erreur est envoyé dans le journal.Il ne faut pas de section [Install] car le script va être piloté par le fichier timer. La ligne Type=oneshot est importante, c’est elle qui dit à systemd de ne pas relancer le service en boucle.
Le fichier “timer” ~/.config/systemd/user/renouvcertif.timer
[Unit]
Description=renouvellement certificat
[Timer]
OnBootSec=3min
OnUnitActiveSec=1d
Unit=renouvcertif.service
[Install]
WantedBy=timers.target
Ceci exécute le fichier .service correspondant 3 minutes après le démarrage et ensuite tous les jours pendant que le système est actif.
Activer le timer
systemctl --user enable renouvcertif.timer
Proxy nginx
Proxy nginx pve.rnmkcy.eu
Le fichier de configuration nginx /etc/nginx/conf.d/pve.rnmkcy.eu.conf
server {
listen 80;
listen [::]:80;
server_name pve.rnmkcy.eu;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name pve.rnmkcy.eu;
# Certificats Let's Encrypt
# TLS 1.3 only
# HSTS (ngx_http_headers_module is required) (63072000 seconds)
# OCSP stapling
# replace with the IP address of your resolver
# Certificats Let's Encrypt
ssl_certificate /etc/ssl/private/rnmkcy.eu-fullchain.pem;
ssl_certificate_key /etc/ssl/private/rnmkcy.eu-key.pem;
# TLS 1.3 only
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/ssl/private/rnmkcy.eu-fullchain.pem;
# replace with the IP address of your resolver
resolver 1.1.1.1;
proxy_redirect off;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://localhost:8006;
proxy_buffering off;
client_max_body_size 0;
proxy_connect_timeout 3600s;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
send_timeout 3600s;
}
}
Valider et recharger ginx
sudo nginx -t
sudo systemctl reload nginx
Web
Ensuite, vous pouvez accéder à votre serveur Proxmox à partir d’un navigateur et de son adresse IP : https://192.168.0.145:8006 ou https://pve.rnmkcy.eu
L’accès est possible en ligne de commande directement sur le serveur, mais je vous propose de basculer sur votre poste de travail pour accéder à votre serveur Proxmox et poursuivre ce tutoriel. Authentifiez-vous sur l’interface Web de Proxmox avec le compte “root” et le mot de passe défini lors de l’installation ou le nouvel utilisateur leno.
Précisions concernant l’option “Realm” du formulaire d’authentification :
- PAM est le module d’authentification enfichable utilisé dans les systèmes d’exploitation Linux/UNIX/BSD pour stocker les informations de l’utilisateur local. Il est stocké au niveau du système et délègue l’autorisation de se connecter à une machine. C’est le module par défaut sous Linux.
- PVE est une base de données stockée dans Proxmox qui stocke des informations sur les utilisateurs pouvant se connecter à l’interface Web de Proxmox. Elle n’accorde pas d’autorisation pour des choses comme la connexion SSH ou Shell au système d’exploitation sous-jacent, au lieu de cela, il délègue uniquement l’autorisation de se connecter aux interfaces Proxmox, comme la WebGUI ou l’API.
Importer un fichier ISO dans Proxmox
Afin de pouvoir installer les systèmes d’exploitation sur nos différentes machines virtuelles, nous devons au préalable télécharger les images système (ISO) et les importer dans Proxmox.
Pour cela, Proxmox dispose d’un élément assez sympa je trouve, une sorte de banque où seront stockés toutes vos images. Procédez comme ceci :
Sélectionnez votre nœud puis le stockage (local, dans notre cas).
Cliquez sur “ISO Images”, puis sur le bouton “Upload” et recherchez l’image à importer sur votre disque local.
Répéter l’opération autant de fois que nécessaire selon la quantité d’images ISO à importer, la seule limite c’est votre espace de stockage.
Les fichiers ISO sont stockés dans le dossier /var/lib/vz/template/iso/
Création machine virtuelle
Pour créer une nouvelle machine virtuelle, il faut cliquer sur le bouton “Create VM” en haut à droite de l’interface.
il faut nommer la machine
Pour un ordonnancement correct, il sera utile de définir une nomenclature de nommage, je vous propose, ceci :
- VM-[ID de la VM] – OS-Nom de la machine
- CT-[ID du conteneur] – OS-Nom de la machine
Le “Resource Pool” ne sera utilisé que si vous avez plusieurs emplacements de stockage sur le Proxmox (pour de l’ordonnancement / backup, etc.).
Sélectionnez à présent l’ISO que vous souhaitez installer sur la machine et le type de système correspondant. Particularité pour une VM freeBSD, on sélectionnera « Other ».
Sachez qu’il est aussi possible d’utiliser directement le lecteur de CD/DVD physique, voir une clé USB directement branchée au serveur.
Pour les conteneurs,les templates préconfigurés sont téléchargeables directement via l’interface et il est demandé si vous souhaitez définir un mot de passe dès la création.
Sur l’écran suivant, on peut configurer certains aspects du système, en cochant « Advanced ». Ainsi, il sera possible de modifier le type de Firmware (BIOS ou UEFI), le type de disque (IDE, SCSI, SATA) et l’émulation SSD, le démarrage automatique, le type de CPU, etc.
L’étape suivante consiste à configurer le stockage de la machine virtuelle, avec le choix du disque dur, son type et sa taille.
À présent, il s’agit de définir les spécifications du CPU, avec éventuellement la possibilité de modifier les vCPU (processeurs virtuels).
Ensuite, nous définissons la quantité de mémoire RAM allouée à cette VM, il est alors possible d’allouer une quantité maximale et minimale (en mode avancé), permettant de limiter la monopolisation des ressources en fonction de l’utilisation de la machine.
La partie Network est assez simple en soi sur une VM, on sélectionne l’interface (Bridge) sur laquelle on souhaite avoir la VM et éventuellement le tag du VLAN (VLAN Tag).
Nous sommes à la dernière étape où nous avons le droit à un résumé. Si cela vous convient, cliquez sur “Terminé” pour créer la machine virtuelle. Cela n’installe pas le système d’exploitation dans la VM, mais la machine sera prête à l’installation.
Notre VM est alors créé et nous pouvons à présent la retrouver dans notre node (partie de gauche de l’interface).
Démarrage VM
Pour pouvoir lancer la VM nouvellement créée, il suffit de faire un clic droit sur l’icône de la machine dans le menu de gauche et de sélectionner “Démarrer”
L’autre option est de la sélectionner la VM, comme nous venons de le faire, puis de sélectionner “Démarrer” en haut à droite de l’écran. D’ailleurs, ce menu comporte un bouton “Plus” qui permet de détruire une machine et son stockage associé, c’est-à-dire le disque virtuel. Ce menu permet aussi de créer un Template (c’est-à-dire un modèle de VM), que l’on pourra cloner à souhait (plutôt pratique).
Une fois la machine démarrée, nous avons accès aux métriques en sélectionnant “Résumé” (charge CPU, RAM, espace de stockage, etc.). De la même façon, il est possible de suivre l’état de votre hyperviseur en sélectionnant : “Datacenter” puis “Résumé”.
Pour accéder à la machine virtuelle ou au conteneur, il suffit de double-cliquer sur son icône dans le menu de gauche. Cette manipulation ouvre une fenêtre qui donne un accès à l’interface graphique de la machine virtuelle. Une alternative est d’utiliser le menu supérieur en haut à droite et sélectionner “Console”
Sur la capture d’écran ci-dessus, on peut voir une flèche sur le côté gauche, celle-ci permet d’avoir accès à des options supplémentaires de la VM, telles que :
- Mettre en plein écran
- Activer une combinaison de touche (CTRL+ALT+SUPPR)
- Démarrage, arrêt, rafraichir l’interface
- Etc…
Note : sous Linux, si vous utiliser CTRL+W pour une recherche avec l’éditeur “nano”, la fenêtre va se fermer sans pour autant éteindre la VM, il faut alors sélectionner [A], puis [CTRL], puis après votre touche [W] afin de permettre la recherche. Une fois le mot trouvé, désactivez la fonctionnalité.
Il ne reste plus qu’à procéder à l’installation du système d’exploitation, que ce soit du Linux ou du Windows !
Erreurs
VM quit/powerdown failed - got timeout
Erreur de délai d’attente
L’erreur de délai d’attente se produit lorsque la machine virtuelle est verrouillée ou que le processus est toujours en cours d’exécution en arrière-plan.
Si la machine virtuelle est verrouillée, nous déverrouillons la VM et l’arrêtons.
Sinon, nous nous connectons au nœud hôte.
Ensuite, nous trouvons le PID du processus de la machine en utilisant la commande.
ps aux | grep "/usr/bin/kvm -id VMID"
ps aux | grep "/usr/bin/kvm -id 100" # VMID=100 dans notre exemple
root 15847 0.5 0.6 3779756 49520 ? Sl 09:58 0:10 /usr/bin/kvm -id 100 -name vm-001-debian11-yunotest -no-shutdown -chardev socket,id=qmp.......................
Une fois que nous avons trouvé le PID, nous tuons le processus en utilisant la commande.
kill -9 15847 # PID=15847 dans notre exemple
Arrêt en mode CLI
Nous avons rencontré de nombreuses instances qui arrêtent la machine virtuelle à partir de l’interface web pour effectuer les tâches.
Ainsi, nous arrêtons la machine virtuelle à partir du nœud. Pour arrêter la VM, il faut d’abord trouver le VMID.
Nous utilisons donc la commande suivante pour arrêter la machine virtuelle
qm stop <VMID>
Ensuite, en rafraîchissant l’interface web, nous pouvons voir que la machine virtuelle est arrêtée.
VM verrouillée
L’une des raisons les plus courantes pour lesquelles il est impossible d’arrêter une machine virtuelle est que celle-ci a été verrouillée. Cela se produit généralement lorsque nous essayons d’arrêter une machine virtuelle alors qu’une sauvegarde est en cours.
La machine virtuelle se verrouille alors pour terminer le processus de sauvegarde. Ainsi, nous pouvons attendre que le processus de sauvegarde supprime la VM. Sinon, nous pouvons déverrouiller la machine virtuelle et l’arrêter.
Pour déverrouiller la VM, nous nous connectons au nœud hôte.
Puis nous trouvons le VMID de la machine virtuelle en utilisant la commande
cat /etc/pve/.vmlist
Une fois que nous avons obtenu le VMID, nous déverrouillons la VM à l’aide de la commande
qm unlock <VMID>
Après avoir déverrouillé la machine virtuelle, nous pouvons supprimer la machine virtuelle à partir de l’interface web ou en utilisant le CLI.