AiHummer
Français▾
ConnexionCompte
v1.0.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Place de marché et plugins/Installation et mises à jour

Installation et mises à jour

v1.0.x · mis à jour 2026-07-05

Installer un plugin dans AiHummer se fait en un seul clic dans l’interface d’administration, mais derrière ce clic se cache un cycle de vie déterministe, natif de l’hôte. La plateforme télécharge le plugin, exécute ses étapes d’installation déclarées, rend un unité systemd en bac à sable, et ne considère le plugin comme sain qu’une fois qu’il répond à un contrôle de santé. Chaque installation se met ensuite à jour elle-même.

Installation en un clic depuis l’interface d’administration

Vous installez et gérez les plugins depuis l’interface d’administration, qui est soutenue par l’API du module d’administration :

GET  /v1/admin/modules
POST /v1/admin/modules/install

Le module slug va dans le corps de la requête JSON, pas dans le chemin :

{ "slug": "einstein", "version": "" }

Il n’y a rien à câbler à la main : choisissez un plugin dans le catalogue, cliquez sur installer, et le déployeur prend le relais.

[!NOTE] Installer un connecteur de canal en dehors de l’ensemble principal (Telegram uniquement) nécessite un actif Démarreur, Affaires ou Entreprise licence. Sur le plan Communautaire, une telle demande retourne HTTP 402 « mise à niveau requise » (code plan_limit) — voir Licence.

[!NOTE] Le Einstein le plugin de mémoire est intégré: il s’installe automatiquement, porte un badge « Intégré » et ne peut pas être retiré ou arrêté.

Le flux SystemdDeployer

Sous le capot, le Déployeur Systemd effectue ces étapes :

  1. Télécharger un tarball pour le plugin sélectionné.
  2. Exécuter le manifeste install[] étapes déclaré par le plugin.
  3. Rendre une unité systemd sandboxée pour le plugin.
  4. Sondage /healthz jusqu’à ce que le service signale qu’il est sain.
download tarball ─▶ run install[] steps ─▶ render sandboxed systemd unit ─▶ poll /healthz ─▶ active

Seulement quand /healthz réussit, l’installation est marquée comme active — un plugin qui ne se lance pas ne compte pas silencieusement comme installé.

Systemd sandboxé natif de l’hôte — pas Docker

Chaque plugin fonctionne en tant que son propre service systemd isolé. Il n’y a pas de conteneurs, pas de Docker, pas d’orchestrateur : un plugin est un service Linux géré avec sa propre unité, son port et ses restrictions de sandbox, supervisé par systemd comme le reste de l’installation.

[!WARNING] AiHummer est natif de l’hôte. Les plugins sont déployés en tant que services systemd isolés à partir d’un paquet tar de distribution — jamais en tant que conteneurs Docker. Si un guide vous dit pour « exécuter le conteneur de plugin », cela ne décrit pas AiHummer.

Contrôle de santé avec /healthz

Le déployeur interroge le plugin /healthz point de terminaison avant de déclarer le succès. Cette barrière de santé est ce qui rend l’installation en un clic sûre : un plugin cassé ou mal configuré est détecté pendant l’installation plutôt que découvert plus tard en production.

Mise à jour automatique par installation

Les mises à jour sont gérées par installation. Chaque plugin installé peut se mettre à jour automatiquement selon son propre calendrier, donc garder les plugins à jour ne nécessite pas une réinstallation manuelle chaque fois qu’une nouvelle version atteint le catalogue. Les mêmes étapes de téléchargement → installation → rendu de l’unité → vérification de santé s’appliquent pour une mise à jour comme pour une première installation.

[!TIP] Parce que la mise à jour automatique se fait par installation, vous pouvez garder certains plugins épinglés tout en permettre aux autres de suivre les dernières nouveautés — chaque installation gère son propre cycle de vie.

Catalogue multisource

Le catalogue n’est plus lié à une seule URL. Le catalogue communautaire des plugins tiers sont livrés en tant que fonctionnalités intégrées source par défaut (préinstallé lors de l’installation) — vous ne l’ajoutez pas vous-même. Dans Plugins → Sources (Interface d’administration, ou POST /v1/admin/modules/catalog/sources) vous pouvez ajouter vos propres sources supplémentaires. La passerelle synchronise chaque source activée au démarrage et à l’intervalle de mise à jour automatique.

  • Le source officielle (les modules de première partie) sont épinglés et fiables par défaut — un objet séparé qui est non écrasé par d’autres sources.
  • Le catalogue communautaire est une source par défaut initialisée ; sources privées sont ajouté par l’opérateur. Chaque entrée de catalogue a une origin, et ça origin décide quelle ancre la signature est vérifiée contre (officiel → clé épinglée, privé → magasin de confiance).

Pour publier dans le catalogue communautaire, voir Publier un plugin.

Modèle de confiance et la clé épinglée

L’installation vérifie la signature d’un plugin par sa source :

  • officielle → vérifié par rapport à clé de registre épinglée dans le noyau. Approuvé par par défaut, aucune action de l’opérateur.
  • privée (chargement latéral) → vérifié par rapport au magasin de confiance de l’instance; le La clé de l’auteur est approuvée par l’opérateur lors du téléchargement (un clic).
  • non signé → rejeté, sauf en mode dev (AIHUMMER_PLUGIN_DEV_UNSIGNED=1, développement local uniquement).

[!WARNING] Les plugins de la communauté ne peuvent pas être installés actuellement — ce n’est pas un problème de connexion. La clé qui signait le catalogue communautaire a été retirée ; tant qu’une nouvelle clé n’est pas livrée, la vérification de signature rejette ces entrées. Indépendamment de cela, le code tiers ne s’exécute pas encore comme service sur votre serveur : tant qu’un environnement d’exécution isolé n’existe pas, seules les intégrations qui tournent de leur côté et se connectent par le réseau sont autorisées.

Ce que vous verrez : après avoir cliqué sur « installer », le message habituel « installation en cours » apparaît, mais le plugin n’apparaît jamais dans la liste des plugins installés. Le motif du refus part dans le journal de la passerelle — ouvrez Journaux dans le panneau d’administration.

Ce qui fonctionne aujourd’hui :

  • les plugins d’AiHummer du catalogue officiel — ils s’installent normalement, ils portent une autre signature, valide ;
  • un serveur MCP en HTTP — branché comme source d’outils sans développement, le code reste chez vous ;
  • une intégration par spécification OpenAPI — pareil, sans service à installer.

Le chargement latéral de votre propre plugin passe la vérification de signature, mais il ne s’exécutera qu’en MCP distant sur HTTP ou en intégration OpenAPI ; une build qui devrait démarrer comme service sur ce même serveur est refusée.

Mises à jour signées

Une mise à jour relance la même porte de signature comme la première installation : lors du passage à une nouvelle version, la signature est à nouveau vérifiée par rapport au même point d’ancrage de confiance. Une mise à jour ne peut pas contourner le chèque — vous ne pouvez pas élever la confiance par une mise à jour.

Le badge officiel et le classement

Dans le catalogue de l’interface Web, les plugins de AiHummer portent un officielle badge et rang premier. Les plugins tiers s’affichent sans badge et se trient par nombre de téléchargements. Le drapeau officiel est dérivé d’une entrée origin (officiel) — il ne peut pas être défini manuellement dans le manifeste.

Où aller ensuite