Non privilégié se mesure, ne se règle pas

Restaurer un conteneur sur Proxmox, c’est le même appel d’API que d’en créer un. On poste vers le point de terminaison des conteneurs sur un nœud, on lui passe l’archive, et on ajoute l’indicateur qui transforme la création en restauration. Le chemin machine virtuelle n’a même pas cet indicateur : là, l’archive elle-même est la restauration. Cette symétrie est commode et elle cache un piège, parce que l’un des champs de cet appel décrit une propriété de sécurité qui possède déjà une valeur à l’intérieur de l’archive.

Envoyez la valeur sûre et vous risquez de casser le conteneur. Omettez le champ et vous risquez de faire entrer un conteneur privilégié dans un parc qui n’est censé n’en compter aucun. Le seul geste correct est de lire l’archive d’abord, puis d’agir sur ce qu’elle dit.

Deux points de terminaison qui se ressemblent

Le chemin machine virtuelle et le chemin conteneur diffèrent en plus d’endroits que le nom ne le laisse croire :

Deux de ces lignes sont faciles à rater d’une manière qui produit une erreur déroutante. Proxmox appelle une archive de conteneur un modèle de système d’exploitation, parce que le même paramètre accepte les deux, et pour une machine virtuelle la présence d’archive est elle-même la restauration, si bien qu’aucun indicateur distinct n’existe. Et images et rootdir sont deux types de contenu différents : un stockage peut offrir l’un sans l’autre, donc exiger images partout rejette des stockages de conteneurs parfaitement bons, tandis que ne rien vérifier du tout tend au client une phrase sur des répertoires de conteneurs qui ne lui dit rien.

De laquelle des deux sortes il s’agit se tranche une seule fois. C’est lu sur le nom de fichier de l’archive au moment où l’archive est listée, conservé avec le point de restauration, et envoyé avec l’instruction ; l’agent choisit son point de terminaison d’après ce mot et n’a aucun repli. Il faut procéder dans ce sens, car un 404 de Proxmox ne distingue pas un invité de l’autre sorte d’un invité qui n’existe plus. Essayer l’autre point de terminaison après un 404 laisserait adresser une machine virtuelle supprimée comme un conteneur, et sur une grappe où ce numéro a depuis été réattribué, c’est le mauvais invité qui serait touché.

Un indicateur n’est jamais envoyé du tout, et il s’appelle force. Il s’agit ici de la restauration additive : une machine apparaît à côté de l’originale et l’originale continue de tourner. force est l’indicateur avec lequel Proxmox écrase un invité existant, il existe sur les deux points de terminaison, et il appartient à l’autre sorte de restauration, laquelle a son propre message, sa propre permission et une confirmation à saisir. Le laisser définitivement hors de ce chemin de code coûte moins cher que de se souvenir de ne pas le poser.

Un indicateur est toujours envoyé, et il s’appelle unique. Sans lui, l’invité restauré hérite des adresses matérielles des cartes réseau de l’original, et deux machines qui répondent à la même adresse, c’est une panne sur la machine que vous preniez justement soin de ne pas toucher.

Trois refus avant que rien ne soit écrit

Chaque contrôle préalable existe parce que l’alternative est une citation de Proxmox sur laquelle un client ne peut pas agir. L’archive doit encore être là, car la plateforme la choisit dans un index qui est par construction une observation du passé. Le numéro cible doit être libre, et libre doit vouloir dire libre sur l’hyperviseur plutôt que libre dans notre propre administration : la plateforme alloue à l’intérieur de la plage qu’elle gère, si bien qu’un invité que quelqu’un a créé à la main est parfaitement réel et parfaitement absent de tous les registres que nous tenons. Et le stockage cible doit accepter le bon type de contenu.

Pour un conteneur, il y en a un quatrième, et c’est celui dont parle cet article.

Trois choses possibles avec une archive privilégiée, et deux sont silencieusement fausses

Les conteneurs non privilégiés sont la valeur sûre par défaut, et la plateforme n’a aucun moyen d’exprimer autre chose. Donc quand une archive se révèle contenir un conteneur privilégié, l’agent a exactement trois options.

La première est d’envoyer quand même l’indicateur non privilégié. Proxmox applique alors une correspondance d’identité sur le système de fichiers restauré ; sa propre description de paramètre dit que le champ ne devrait pas être modifié à la main. La restauration réussit, la tâche se déclare correcte, et le conteneur ne fonctionne pas.

La deuxième est d’omettre le champ. Proxmox reprend alors la valeur de l’archive, et un conteneur privilégié rejoint le parc : un conteneur qui partage le noyau de l’hôte avec les privilèges root, c’est-à-dire la chose même que la politique existe pour empêcher.

La troisième est de refuser, avec une phrase disant ce que contient l’archive. C’est ce qui se passe, et cela se passe avant que rien ne soit écrit. Aucune demande de création du conteneur n’est envoyée.

Lire la configuration qui se trouve dans l’archive

La mesure est un appel au point de terminaison d’extraction de l’archive. Trois détails méritent d’être connus.

La réponse est du texte et non du JSON. C’est le fichier de configuration du conteneur, une clé et une valeur par ligne, exactement tel qu’il se trouve sur le disque, il lui faut donc son propre petit analyseur à côté de celui qui traite le JSON de l’API.

Et l’absence de la clé veut dire le contraire de ce qu’une absence veut dire d’habitude. Proxmox n’écrit la ligne non privilégié que lorsqu’elle est vraie. Une configuration qui ne la porte pas décrit un conteneur privilégié. Tout lecteur qui traite « introuvable » comme « inconnu, probablement sans souci » laisse passer précisément le cas pour lequel le contrôle a été construit ; la comparaison est donc généreuse sur ce qu’elle accepte comme vrai et refuse tout le reste.

Si la configuration ne peut pas être lue du tout, la restauration est refusée également, et la citation de Proxmox revient avec elle. C’est en général un message de permissions, car le point de terminaison d’extraction veut des droits de sauvegarde sur l’invité et des droits d’allocation sur le stockage de sauvegarde. Refuser par défaut ici a un coût réel : un jeton d’API auquel il manque une permission ne peut pas restaurer un conteneur, et la raison en est un contrôle plutôt qu’une limitation. C’est tout de même le bon côté sur lequel échouer, car la question ouverte derrière a deux réponses silencieusement fausses.

La même lecture répond à une seconde question

La configuration à l’intérieur de l’archive dit aussi quels points de montage en faisaient partie, et les règles de Proxmox là-dessus ne sont pas celles que l’on attend :

La troisième ligne est la dangereuse. Sur un disque de machine virtuelle, exclu est l’exception et inclus est le défaut ; sur un point de montage de conteneur, c’est l’inverse. Se tromper là-dessus produit un tableau de couverture qui dit « dans la sauvegarde » à propos de la configuration la plus répandue qui soit, ce qui est pire que de n’avoir aucun tableau, car c’est une promesse.

Les sections d’instantané de la configuration sont ignorées. Un conteneur avec cinq instantanés apporterait sinon cinq versions du même système de fichiers racine, chacune prise à un moment arbitraire.

Un seul appel sert les deux questions plutôt que deux, car deux appels pourraient décrire deux archives différentes. Et le verdict est calculé sur la plateforme, pas par l’agent : l’agent rapporte les lignes telles qu’il les a trouvées, et il n’existe aucun champ dans lequel il pourrait affirmer une couverture complète même s’il le voulait. Démontrablement hors de la sauvegarde vaut mieux que non mesuré, donc un conteneur avec un point de montage bind et une ligne illisible est partiel plutôt qu’inconnu, et la ligne illisible garde son propre mot dans le tableau.

Il y a un indicateur disant si la configuration a été lue, et ce n’est pas une décoration. Un agent qui n’a pas pu la lire renvoie une liste vide, et une liste vide est indiscernable d’un conteneur sans aucun point de montage, sauf que le second n’existe pas.

Quand personne ne peut dire ce qui s’est passé

Une restauration qui démarre puis perd sa réponse, parce que l’agent a redémarré ou que la connexion est tombée, ne doit pas être devinée. Il y a trois sources de preuve : l’index des archives, la machine censée apparaître, et le statut de la tâche Proxmox. Seule la troisième peut établir un échec ; les deux autres ne peuvent que confirmer une réussite, car une archive absente et une machine absente sont toutes deux également compatibles avec une restauration encore en cours.

Ce raisonnement se fait sur la plateforme. La consultation de la tâche par l’agent ne fait que rapporter la citation de Proxmox et n’en tire aucune conclusion propre, car décider de ce que les trois sources donnent ensemble demande d’avoir côte à côte l’exécution et l’intention dont elle est partie, et seule la plateforme a les deux.

Rien n’est réessayé indéfiniment. Il y a un compteur dont le plafond est de huit tentatives, et à l’intervalle par défaut de six heures cela revient à environ deux jours. Les tentatives où la tâche tournait manifestement encore ne comptent pas contre lui, car une grosse sauvegarde sur un réseau lent a le droit de prendre une nuit. Quand le compteur est épuisé, l’exécution devient inconnue, et jamais échouée. Échouée serait une affirmation que personne n’a vérifiée, et terminée affirmerait une archive que personne n’a vue.

Ce que nous retiendrions

1. 01N’envoyez pas de valeur pour une propriété qui existe déjà dans l’entrée. Lisez-la, puis confirmez-la ou refusez.
2. 02Cherchez ce que signifie une clé absente avant d’écrire l’analyseur. Ici elle signifie la valeur risquée, ce qui est le contraire de la convention habituelle.
3. 03Refusez par défaut quand la mesure n’est pas disponible, et dites tout haut ce que cela coûte, parce que quelqu’un tombera dessus.
4. 04Faites qu’une seule lecture réponde à toutes les questions qu’elle peut. Deux appels peuvent décrire deux états différents.
5. 05Placez le jugement là où se trouve le contexte. Un observateur incapable d’exprimer un verdict ne peut pas se tromper de verdict.
6. 06Donnez à une reprise épuisée son propre mot terminal. Inconnue est honnête ; échouée et terminée sont deux affirmations que personne n’a faites.

Pour être clair sur ce dont il s’agit : les sauvegardes clients sont derrière un indicateur de déploiement désactivé par défaut, si bien que rien de tout cela n’est achetable aujourd’hui. Et la limite importante sur les preuves : aucune sauvegarde ni restauration réelle n’a été exécutée contre un hyperviseur en fonctionnement. Le comportement des paramètres ci-dessus a été lu dans les sources et la documentation de Proxmox, et le code a été éprouvé contre un serveur de substitution qui répond aux mêmes points de terminaison. L’appel d’extraction n’a pas non plus été essayé contre une archive posée sur un serveur de sauvegarde dédié, seulement contre un stockage sur fichiers.

Issu du travail sur les sauvegardes chez Provibr. Pourquoi une archive que personne n’a restaurée n’est pas encore une sauvegarde est dans une sauvegarde jamais restaurée, ce que les différents modes de sauvegarde garantissent réellement est dans les modes vzdump de Proxmox, et pourquoi réinstaller un conteneur est une destruction suivie d’une reconstruction est dans réinstaller un conteneur, c’est le remplacer.