Questions fréquentes

Une plateforme de gestion de serveurs pour ceux qui exploitent leur propre infrastructure. Vous gardez vos hyperviseurs, votre réseau et vos contrats de centre de données ; Provibr vous donne, à vous et à votre équipe, un seul panneau pour les piloter, ainsi que la mécanique pour attribuer de la capacité à des clients.

Des hyperviseurs pour les machines virtuelles, des panneaux de contrôle pour les comptes d’hébergement et des panneaux de jeu pour les serveurs de jeu. Les serveurs dédiés, les équipements réseau et la distribution d’énergie sont sur la feuille de route. La page des intégrations porte le statut exact de chaque fournisseur, disponible ou sur la feuille de route, de sorte que cette réponse ne peut jamais prendre du retard en silence.

Non. Provibr dialogue avec l’API de Proxmox à l’aide d’un jeton que vous créez, depuis un agent qui tourne sur un hôte Linux distinct du même réseau. Rien n’est installé sur l’hyperviseur lui-même et aucun port Proxmox n’a besoin d’être joignable depuis l’extérieur.

Oui, et c’est le fonctionnement prévu. Vous enregistrez vos préfixes, leurs passerelles et la plage utilisable dans la gestion des adresses de la plateforme, et les machines reçoivent une adresse du pool vers lequel pointe leur plan.

La liste complète se trouve dans le sélecteur de langue en haut de chaque page : 9 langues aujourd’hui. Le panneau, ce site et les messages que votre agent génère sont tous traduits, afin que le même événement se lise correctement pour toute votre équipe. L’outil en ligne de commande et tout ce que vous collez dans un shell restent volontairement en anglais.

Oui. Il existe une API REST publique pour les serveurs, les agents, les intégrations, les adresses, les plans, la facturation et les webhooks ; vous créez une clé sur votre propre page de profil, et elle porte un droit par partie du panneau, jamais plus que vos propres droits. Comme votre agent se connecte vers l’extérieur, un endpoint qui modifie une machine accepte l’ordre et vous remet de quoi en suivre la suite au lieu de répondre par le résultat. La documentation décrit chaque endpoint et renvoie vers le document OpenAPI 3.1.

Sur l’hôte de l’agent, chiffrés dans un coffre dont la clé est mélangée à l’identité propre de cette machine. Ils traversent la plateforme une seule fois, en transit, pour atteindre l’agent. L’enregistrement d’audit de ce transfert conserve le nom des champs, jamais les valeurs, et la plateforme ne peut pas reconstituer le jeton ensuite.

TLS 1.3 avec authentification mutuelle. L’enregistrement et la session de travail utilisent des endpoints distincts, et sur l’endpoint de session la plateforme épingle l’empreinte du certificat de l’agent : un certificat volé sans la clé correspondante ne mène à rien.

La session est fermée et l’agent efface sa propre identité et son coffre d’identifiants. À partir de cet instant, il ne détient plus rien d’utile : aucun certificat, aucun jeton, aucun moyen de revenir sans une nouvelle licence et un nouvel enregistrement.

Oui, avec une signature sur le binaire brut. Elle est vérifiée par l’agent avant la préparation, puis de nouveau par un script appartenant à root avant l’exécution du binaire, contre une clé publique que seul root peut remplacer. Une version non signée ou modifiée est refusée, même si sa somme de contrôle correspond.

Non. Chaque requête, chaque canal temps réel et chaque événement est limité à une seule organisation, et la connexion temps réel est autorisée par un ticket à usage unique rattaché à votre organisation avant même l’ouverture du socket.

Oui. Les commandes, leurs résultats, les connexions et déconnexions d’agents, les changements de statut des intégrations, les attributions d’adresses, les changements de forfait et les événements de facturation aboutissent tous dans un journal d’activité que vous pouvez parcourir et filtrer. Il est conservé, et non purgé au bout d’une journée.