|
|
[[_TOC_]]
|
|
|
|
|
|
# Mise en place des certificats LetsEncrypt pour l'interface web de Proxmox
|
|
|
|
|
|
Les certificats sont gérés avec [Certbot](https://certbot.eff.org/docs/using.html), ceux-ci sont créé avec la commande :
|
|
|
```
|
|
|
certbot certonly --cert-name proxmox.gresille.org -d proxmox.gresille.org
|
|
|
```.
|
|
|
|
|
|
Cette commande, avec l'option `certonly`, va juste créer les certificats dans le dossier `/etc/letsencrypt/live/proxmox.gresille.org`.
|
|
|
|
|
|
Il est nécessaire ensuite de placer ceux-ci dans le dossier de l'interface PVE de Proxmox, ce qui rapidement fait avec les commandes
|
|
|
```
|
|
|
cp /etc/letsencrypt/live/proxmox.gresille.org/fullchain.pem /etc/pve/nodes/proxmox/pve-ssl.pem
|
|
|
cp /etc/letsencrypt/live/proxmox.gresille.org/privkey.pem /etc/pve/nodes/proxmox/pve-ssl.key
|
|
|
```
|
|
|
|
|
|
Enfin il faut redémarrer PVE Proxmox pour que celui-ci charge les nouveaux certificats :
|
|
|
```
|
|
|
service pveproxy restart
|
|
|
```.
|
|
|
|
|
|
Ensuite ces certificats doivent être renouvelés quand ceux-ci arrivent à expiration. Certbot, ayant été installé via le paquet des dépôts Debian, est configuré pour les renouveler automatiquement (plus d'infos sur les renouvellement [ici](https://certbot.eff.org/docs/using.html#renewing-certificates)). Il est nécessaire d'ajouter quelques commandes à executer avant les tentatives de renouvellement (par exemple arréter un service qui pourrait géner la tentative) ou après (ici, on veut pouvoir placer les nouveaux certificats au bon endroit et redémarer pveproxy).
|
|
|
|
|
|
Les commandes peuvent être placées dans les sous-dossiers `pre` (commandes avant la tentative de renouvellement), `post` (commandes après la tentative de renouvellement), `deploys` (commandes après une tentative réussie de renouvellement) du dossier `/etc/letsencrypt/renewal-hooks/`. Dans notre cas nous allons ajouter un script à executer après un renouvellement réussi :
|
|
|
|
|
|
```
|
|
|
#! /bin/sh
|
|
|
#
|
|
|
cp /etc/letsencrypt/live/proxmox.gresille.org/fullchain.pem /etc/pve/nodes/proxmox/pve-ssl.pem
|
|
|
cp /etc/letsencrypt/live/proxmox.gresille.org/privkey.pem /etc/pve/nodes/proxmox/pve-ssl.key
|
|
|
service pveproxy restart
|
|
|
```
|
|
|
|
|
|
Il ne faut pas oublier de rendre executable le script avec la commande :
|
|
|
```
|
|
|
chmod a+x /chemin/vers/script
|
|
|
```
|
|
|
|
|
|
Enfin on peut tester la validité de notre configuration en executant un renouvelement test pour voir si tout fonctionne :
|
|
|
```
|
|
|
certbot renew --dry-run
|
|
|
```
|
|
|
Lors de cette tentative, l'execution (du moins, la non-execution) des scripts de pré-post-deploy doit apparaître en rouge.
|
|
|
|
|
|
Et c'est tout...
|
|
|
|
|
|
|
|
|
# Clustering
|
|
|
|
|
|
La mise en "cluster" permet aux hyperviseurs de communiquer entre eux et de migrer des VM d'un serveur à l'autre. Une fois le cluster activé, les hyperviseurs synchronisent leur configuration : utilisateurs, liste des VM... L'exception est le stockage puisque c'est une notion locale (mais certaines opérations comme la réplication demandent que le nom des pools de stoackage soient cohérent).
|
|
|
|
|
|
On peut se connecter indifféremment sur n'importe quel machine du cluster pour administrer l'ensemble des machines.
|
|
|
|
|
|
## Mise en place d'un réseau dédié
|
|
|
|
|
|
Il est très fortement conseillé de mettre en place un réseau dédié entre les serveurs. Il sera utilisé pour le traffic de "contrôle" (corosync pour la détection de panne, SSH) et également pour la migration de VM. Si vous avez des SSD ou disques rapides, il est conseillé que ce réseau soit en 10 Gbit/s, mais pour des besoins basiques un réseau 1 Gbit/s peut suffir.
|
|
|
|
|
|
Configurer ce réseau en IP statique avec la conf Debian standard (`/etc/network/interfaces`).
|
|
|
|
|
|
## Activation du clustering
|
|
|
|
|
|
La documentation officielle est plutôt claire : https://pve.proxmox.com/wiki/Cluster_Manager
|
|
|
|
|
|
Bien choisir la bonne interface réseau (réseau dédié).
|
|
|
|
|
|
Attention : il faut que les hyperviseurs "secondaires" qui rejoignent le cluster n'aient aucune VM.
|
|
|
|
|
|
Une fois le cluster formé, il ne semble y avoir aucune différence entre la machine qui a créé le cluster et celles qui ont rejoint le cluster : elles ont toutes le même rôle à la fin.
|
|
|
|
|
|
# Gestion des comptes proxmox
|
|
|
|
|
|
TODO: pour l'instant, les comptes utilisateurs sont créés manuellement (en mode PVE), mais il faudrait automatiser / relier ça à une base utilisateur genre Epeire.
|
|
|
|
|
|
# Droits d'accès
|
|
|
|
|
|
Chaque utilisateur a accès à sa machine virtuelle sur l'interface web de
|
|
|
Proxmox. Il peut accéder à la console (VNC / série), rebooter sa machine,
|
|
|
mettre un CD virtuel...
|
|
|
|
|
|
## Comment ça marche ?
|
|
|
|
|
|
Référence : [la doc officielle (en anglais)](https://pve.proxmox.com/wiki/User_Management)
|
|
|
|
|
|
Proxmox propose tout un tas de privilèges (Privileges), pour que chaque action
|
|
|
dans l'interface soit contrôlable. Elle propose un ensemble de rôles (Roles)
|
|
|
prédéfinis, qui ont chacun un ensemble de privilèges pour un usage spécifique.
|
|
|
Par exemple :
|
|
|
|
|
|
* `Administrator` : le super-utilisateur, qui a tous les droits ;
|
|
|
* `PVEUserAdmin` : il peut gérer les utilisateurs et groupes ;
|
|
|
* `PVEVMAdmin` : il a tous les droits sur une (ou plusieurs) machines virtuelles ;
|
|
|
* `PVEVMUser` : il peut voir tous les paramètres d'une VM, la sauvegarder, accéder à la console pour la redémarrer et booter sur un CD ;
|
|
|
* `GresilleUser` : même chose que PVEVMUser, et peut gérer
|
|
|
* etc.
|
|
|
|
|
|
Le rôle `GresilleUser` sera le rôle de base des utilisateurs, car il permet
|
|
|
l'utilisation courante d'une machine virtuelle sans risque d'erreur. On peut
|
|
|
envisager ajouter des droits pour les utilisateurs avancés, ou même de réévaluer
|
|
|
les droits pour tous.
|
|
|
|
|
|
|
|
|
Mais ces rôles doivent ensuite être associés à un objet (Object), un stockage
|
|
|
(Storage) ou un pool de ressources (Pool). Le rôle `GresilleUser` n'a de sens
|
|
|
qu'une fois associé à une (ou plusieurs) VM. Les droits spécifiques à la gestion
|
|
|
des disques se font sur les stockages. Les pools ne sont actuellement *pas*
|
|
|
utilisés chez Grésille.
|
|
|
|
|
|
## Exemple pratique
|
|
|
|
|
|
Nous allons créer un utilisateur lambda, qui aura juste les droits
|
|
|
`GresilleUser` sur sa machine virtuelle.
|
|
|
|
|
|
Dans la vue Server View, aller sur Datacenter dans le panneau de gauche, puis
|
|
|
sélectionner Permissions > Users. Remplir le username avec le login souhaité,
|
|
|
Realm à "Proxmox VE Authentication server", un mot de passe (qui ~~pourra~~
|
|
|
devra être changé), le mettre dans le groupe "users", et vérfier que la case
|
|
|
Enabled est cochée. Idéalement, prendre une adresse mail ou autre moyen de
|
|
|
contact.
|
|
|
|
|
|
On peut ensuite lui créer une machine virtuelle (bouton "Create VM" en haut à
|
|
|
droite), en remplissant les différents éléments (TODO: faire une doc pour la
|
|
|
création des VM, surtout sur l'aspect réseau).
|
|
|
|
|
|
Enfin, dans le panneau de gauche, chercher la nouvelle machine. Aller dans ses
|
|
|
permissions, et ajouter notre nouvel utilisateur en User, et lui mettre le rôle
|
|
|
de `GresilleUser`. Si l'utilisateur est déjà connecté, il devra se reconnecter
|
|
|
pour que les permissions soient bien relues, et qu'il récupère bien tous les
|
|
|
droits.
|
|
|
|
|
|
# Configuration réseau
|
|
|
|
|
|
## Principe
|
|
|
|
|
|
On aimerait isoler le réseau des VM entre elles, comme pour les machines physiques. Voir [Fonctionnement du réseau](Infra/Fonctionnement du réseau) pour le contexte.
|
|
|
|
|
|
Plusieurs pistes :
|
|
|
|
|
|
- soit un VLAN par VM qui remonte jusqu'au routeur principal. Ça peut faire beaucoup de VLAN mais au moins c'est uniformisé : ça marche pareil pour les machines physiques et virtuelles
|
|
|
- soit un VLAN unique qui remonte au routeur principal pour toutes les VM, mais on isole les VM entre elles (isolation des ports clients d'un bridge possible sous Linux ? un peu comme private VLAN)
|
|
|
- soit un bridge séparé par VM, et l'hyperviseur sert de routeur/gateway pour les VM. On peut faire du BGP entre le routeur principal et les hyperviseurs, à la tetaneutral.
|
|
|
|
|
|
On est parti sur la solution 1, la plus uniforme.
|
|
|
|
|
|
## Configuration avec un bridge unique et des VLAN
|
|
|
|
|
|
On décide de mettre un seul bridge `vmbr0`, bridgé avec l'interface physique de la machine physique, pour des questions de simplicité (cf paragraphe suivant)
|
|
|
|
|
|
Ensuite, à la création de la VM, on l'associe à ce bridge unique mais on spécifie un tag VLAN dans la configuration réseau.
|
|
|
|
|
|
Il faut évidemment que le port du switch connecté à l'hyperviseur soit en mode "trunk" pour autoriser les paquets avec un tag VLAN.
|
|
|
|
|
|
## Pour info : configuration avec un bridge par VM
|
|
|
|
|
|
Sur la machine physique, pour chaque VM, créer un bridge `vmbrXXX` bridgé avec une interface virtuelle `eno1.XXX`. Dans `/etc/network/interfaces`:
|
|
|
|
|
|
```
|
|
|
auto vmbrXXX
|
|
|
iface vmbrXX inet manual
|
|
|
bridge-ports eno1.XXX
|
|
|
bridge-stp off
|
|
|
bridge-fd 0
|
|
|
```
|
|
|
|
|
|
Lors de la création de la VM, l'associer au bridge `vmbrXXX` correspondant à son numéro de VLAN.
|
|
|
|
|
|
**Problème de cette méthode :** il faut créer tous les bridges sur toutes les proxmox du cluster pour pouvoir migrer les VM entre les différents proxmox. C'est donc pénible.
|
|
|
|
|
|
# Configuration du stockage
|
|
|
|
|
|
On part sur du ZFS. Il suffit de créer un pool ZFS dans l'interface d'admin, en spécifiant la liste des disques à utiliser (mode miroir avec deux disques). On peut créer un pool ZFS en SSD et un autre pool en HDD : il faudra choisir le pool désiré lors de la création ou migration de la VM.
|
|
|
|
|
|
Si on est un peu short en mémoire sur les hyperviseurs, penser [à baisser la taille du cache ZFS](https://pve.proxmox.com/wiki/ZFS_on_Linux#_limit_zfs_memory_usage). Il faut rebooter pour que ce changement s'applique.
|
|
|
|
|
|
Penser à désactiver le stockage de VM sur le disque système Proxmox, sinon il y a un risque de se tromper de stockage à la création de VM... C'est dans Datacenter / Storage, éditer le stockage "local" et enlever "Disk image".
|
|
|
|
|
|
# Gestion des machines virtuelles
|
|
|
|
|
|
## Migration "à chaud"
|
|
|
|
|
|
Il s'agit de déplacer une VM d'un hyperviseur à un autre, alors que la VM est allumée. Du point de vue de la VM, c'est complêtement transparent, avec un "freeze" de la VM d'environ 50 millisecondes.
|
|
|
|
|
|
Commencer par s'assurer qu'il y a la place sur le serveur de destination (assez de RAM et d'espace disque).
|
|
|
|
|
|
Sélectionner la VM et cliquer sur "Migrate", puis choisir le serveur de destination et le stockage. Voilà : proxmox va copier le disque, puis la RAM, puis basculer la VM.
|
|
|
|
|
|
## Migration "à froid"
|
|
|
|
|
|
Même principe, mais avec une VM éteinte.
|
|
|
|
|
|
Visiblement Proxmox refuse si le stockage n'a pas le même nom sur le serveur de départ et d'arrivée...
|
|
|
|
|
|
TODO
|
|
|
|
|
|
## Réplication
|
|
|
|
|
|
TODO |