Vendre de l’hébergement avec Virtualmin

Virtualmin est l’un des plus anciens panneaux de contrôle encore réellement utilisés (il existe depuis 2004) et il dispose d’un parc installé que GitHub ne montre pas. Le 21 août 2026, le dépôt comptait 412 étoiles, 129 forks et 46 contributeurs. C’est peu au regard de GitHub, et cela ne dit presque rien du nombre de petits hébergeurs qui l’exploitent.

Ce que cela dit, en revanche, c’est qu’il a été très peu écrit sur la vente avec Virtualmin. Cette page est exactement cela : comment Provibr se connecte à une machine Virtualmin, quelles décisions le panneau vous impose, et où se trouvent les arêtes vives. Tout ce qui suit a été mesuré sur une installation réelle de Virtualmin GPL 8.1.2 sous Ubuntu 24.04.

Webmin est le panneau, Virtualmin fait l’hébergement

Vous connaissez le produit sous le nom de Webmin. C’est le nom sur la page de connexion, dans la documentation et dans toutes les recherches. Mais Webmin seul administre une machine Linux : il ne connaît absolument pas la notion de compte d’hébergement. Ce que Provibr pilote réellement, c’est Virtualmin : le module qui connaît les domaines, les forfaits et les quotas.

C’est plus important qu’il n’y paraît. Sur une machine sans ce module, le point d’accès de l’API distante de Virtualmin n’existe simplement pas : il répond exactement comme un nom de module que vous auriez inventé. Cela a été mesuré à l’étape zéro de l’étude, avant toute installation. Il n’y a donc pas de repli sur Webmin seul, et Provibr ne fait pas semblant : la connexion est refusée avec un motif plutôt que créée à moitié.

Ce qu’il faut pour se connecter

Quatre champs, dont deux plus stricts que pour tout autre panneau de contrôle pris en charge.

Pourquoi https et l’empreinte sont tous deux imposés. Nos autres intégrations de panneaux de contrôle acceptent une adresse http simple et vous disent ce que cela coûte. Celle-ci non, et la différence tient à la nature du secret.

L’API distante de Webmin parle HTTP Basic. Le secret est ici un mot de passe et non un jeton : c’est une propriété de Webmin, pas un choix de notre part. Une clé de connexion DirectAdmin peut être restreinte à une poignée de commandes ; un mot de passe Webmin ne peut être restreint en rien. L’envoyer en clair, ou vers un certificat que personne n’a vérifié, n’est pas un arbitrage que nous faisons à votre place. Et l’installateur de Webmin laisse un certificat auto-signé, le champ d’empreinte n’est donc pas théorique : c’est le cas normal.

Conseil pratique : créez un utilisateur Webmin dédié et donnez-lui le module Virtualmin. Il pourra tout ce que Virtualmin sait faire, ce qui est déjà beaucoup, mais pas tout ce que Webmin sait faire.

Deux choses qui mordront une intégration

Ce sont les deux comportements mesurés les plus susceptibles de vous coûter un après-midi si vous construisez cela vous-même.

Toute erreur arrive en HTTP 200. Virtualmin connaît deux formes d’échec (error au niveau de l’enveloppe et failure au niveau du programme) et livre les deux avec un code 200. Le code de statut ne dit rien. Tout ce qui n’est pas exactement status: "success" est un échec, et l’erreur d’enveloppe doit être vérifiée avant toute comparaison de texte, faute de quoi « Remote program xyz does not exist » se lit comme un compte absent.

(C’est un trait de famille des API de panneaux de contrôle, pas une bizarrerie de Virtualmin. DirectAdmin fait la même chose autrement : HTTP 200 avec error=1 dans le corps. Une intégration qui se fie au code de statut réussit en silence alors que rien ne s’est produit.)

Un chemin d’interface répond 200 avec une page de connexion. Si vous visez un chemin de module Webmin au lieu de l’API distante, vous obtenez un HTTP 200 avec une page HTML de connexion : pour un mot de passe faux, un mot de passe juste et aucun mot de passe, indiscernables au niveau du code de statut. L’API distante, elle, répond proprement par une 401. C’est cette différence qui rend l’erreur exploitable : un 200 avec du HTML ne peut signifier qu’une chose, à savoir que vous ne visez pas l’API. Provibr le dit par son nom, au lieu de vous montrer une erreur d’analyse JSON sur un panneau qui fonctionne très bien.

Sur certaines installations, cette route est désactivée. Vous la réactivez sous Webmin → Webmin Configuration → Advanced Options.

Réglages : il n’y en a pas

Un serveur Virtualmin décide lui-même où vit un compte et quelle adresse il reçoit. Il ne vous reste rien à choisir, l’onglet des réglages ne porte donc rien d’autre que le renvoi des identifiants.

Cela vaut aussi pour l’adresse IP. Virtualmin place un compte sur l’adresse partagée de l’hôte par défaut. Nous avons mesuré ip_address renvoyant 192.0.2.10 (Shared). La gestion d’adresses de Provibr reste donc désactivée pour ce fournisseur. Une gestion d’adresses qui laisserait croire qu’elle attribue l’adresse mentirait.

Les forfaits

Un forfait Virtualmin est la description qu’a le panneau d’un compte : quota de disque, trafic mensuel, nombre de domaines et de boîtes aux lettres, fonctions activées. Ce n’est pas un forfait Provibr ni un système d’exploitation : c’est un nom auquel nous nous référons, et son contenu peut changer sur votre serveur sans que nous le sachions.

La page d’intégration lit la liste des forfaits avec leur contenu, afin que vous voyiez ce que vous choisissez plutôt que de saisir un nom de mémoire. Un forfait web Provibr épingle ensuite un forfait Virtualmin sur une intégration et lui donne un nom à vous. Commander via un forfait l’emporte sur une sélection libre, et le sélecteur libre reste disponible pour les cas qu’un forfait ne couvre pas.

⚠️ Un piège mesuré mérite d’être connu : modify-domain avec un nom de forfait inexistant répond status: "success" et laisse le forfait exactement là où il était. Il n’y a donc aucune forme d’erreur à classer : le refus est le silence. Provibr compare ce qui a été demandé à ce qu’il relit ensuite ; un changement de forfait qui n’a pas eu lieu est signalé comme n’ayant pas eu lieu.

À quoi ressemble un compte dans Provibr

Un compte d’hébergement est une ligne de serveur ordinaire, de type webserver. En créer un demande un domaine, une adresse e-mail, un forfait et un mot de passe.

• L’identifiant est le numéro interne que Virtualmin attribue au domaine, pas le nom. Virtualmin peut renommer un domaine ; une clé fondée sur le nom se détache de sa ligne dès la première fois.
• L’utilisateur Unix est dérivé du domaine : mon-client.fr donne mon-client. Les traits d’union sont ici la forme normale et non l’exception, et la limite est celle de Linux lui-même, 32 caractères. Cela diffère de DirectAdmin et de cPanel, qui imposent leurs propres règles plus strictes.
• La frontière du compte est l’utilisateur Unix, pas le domaine. Les sous-serveurs et les alias tomberaient sinon chacun dans le décompte de licence comme un compte d’hébergement distinct.
• Le mot de passe n’est consigné nulle part. Seul le fait que vous en ayez fourni un l’est ; la valeur voyage séparément et n’atterrit jamais dans une ligne d’audit.
• Vous pouvez ensuite suspendre, réactiver, changer de forfait et supprimer. Il n’y a pas de console : un compte d’hébergement n’en a pas.

Suspendu signifie qu’un champ existe

C’est le détail le plus fin de toute l’intégration, et c’est précisément ce qu’un analyseur maison rate.

Sur un compte suspendu, list-domains gagne un champ nommé disabled. Sur un compte actif, ce champ est tout simplement absent. Il n’existe pas de disabled: "No".

Un analyseur qui cherche une valeur n’en trouve jamais et lit tous les comptes comme actifs, y compris les suspendus. Dans un contexte de facturation, ce n’est pas un défaut cosmétique : un compte que vous avez suspendu pour impayé se déclare actif, et votre décompte de capacité est faux dans le sens qui vous coûte de l’argent.

Quotas et utilisation : parfois il n’y a rien à montrer

Le quota de disque et le trafic voyagent avec le relevé habituel : un compte obtient donc son graphique d’utilisation sans qu’il faille activer quoi que ce soit, à condition que le serveur puisse les mesurer.

Virtualmin ne remonte quotas et utilisation que si les quotas du système de fichiers sont activés, et une installation neuve les a désactivés. Nous l’avons mesuré : quotaon -p / a répondu off sur une installation standard, parce que l’installateur écrit l’ancien format de quota dans /etc/fstab alors qu’un noyau ext4 moderne attend des quotas journalisés. Tant que personne ne les active, aucun champ de quota n’apparaît dans la sortie de l’API.

Provibr n’affiche alors rien plutôt qu’un zéro. Absence de mesure et absence d’utilisation ne sont pas la même chose, et un graphique bloqué à zéro ressemble à la seconde alors qu’il s’agit de la première.

Une note connexe si vous lisez un jour la sortie brute vous-même : préférez les champs lisibles par machine (created_unix_time, databases_byte_size) à leurs jumeaux humains (created_on, databases_size). Les seconds portent des unités et un format de date qui dépendent de la langue du panneau, et les analyser est exactement le genre d’échec silencieux qui se manifeste d’abord chez un client au réglage différent.

Deux omissions volontaires

Le test de connexion n’affiche pas de ligne de version. Virtualmin n’a aucun programme d’API qui renvoie sa propre version : virtualmin info connaît vingt et une clés de recherche et aucune version, et l’en-tête Server: MiniServ ne porte pas de numéro. Une ligne vide prétendrait que nous avons essayé sans y parvenir ; l’omettre dit la vérité. Le test montre à la place votre liste de forfaits, qui est ce que vous voulez réellement vérifier.

Et rien de secret n’est stocké depuis le panneau. list-domains --multiline porte littéralement hashed_password, password_for_mysql et password_storage dans sa sortie. Provibr filtre avec une liste blanche avant de lire, et non par caviardage a posteriori : une liste noire manque par construction le prochain secret qui portera un autre nom. Nous l’avons vérifié par une contre-épreuve dans la même exécution : la réponse brute du panneau porte bien ces trois champs, et la liste d’import n’en contient aucun.

Reprendre des comptes existants

L’onglet d’import liste les comptes présents sur le panneau et vous laisse reprendre ceux que vous voulez dans Provibr. Les comptes déjà connus sont affichés mais non sélectionnables, afin que vous voyiez l’image entière et non une image filtrée.

Les comptes importés comptent dans votre capacité exactement comme les comptes commandés. Importez-en plus que vous n’avez de place et un dépassement s’ouvre, avec le délai de grâce habituel.

Ce que cela change pour un petit hébergeur

Virtualmin vous donne un panneau d’hébergement solide et aucune couche commerciale. Le conseil habituel (passez à quelque chose que les systèmes de facturation parlent déjà) vous demande de déplacer des clients en production hors d’une machine qui fonctionne, pour résoudre un problème administratif.

Provibr se connecte à des panneaux de contrôle, des hyperviseurs et des panneaux de jeu côte à côte. Gardez la machine Virtualmin que vous avez, posez dessus la commande et le décompte de capacité, et ajoutez à côté un VPS ou un panneau de jeu l’an prochain sans rien changer au fonctionnement de la partie hébergement.