Instalar y actualizar

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

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

download tarball ─▶ run install[] steps ─▶ render sandboxed systemd unit ─▶ poll /healthz ─▶ active

Instalar un plugin en AiHummer es un solo clic en la interfaz de administración, pero detrás de ese clic hay un ciclo de vida determinista, nativo del host. La plataforma descarga el plugin, ejecuta sus pasos de instalación declarados, renderiza un **unidad systemd en sandbox**, y solo considera que el complemento está saludable una vez que responde a una verificación de estado. Cada instalación luego se mantiene actualizada por sí misma. ## Instalación con un clic desde la interfaz de administración Instalas y gestionas plugins desde la interfaz de administración, que está respaldada por la API del módulo de administración: ```http GET /v1/admin/modules POST /v1/admin/modules/install ``` El identificador del módulo va en el cuerpo de la solicitud JSON, no en la ruta: ```json { "slug": "einstein", "version": "" } ``` No hay nada que cablear a mano: elige un complemento del catálogo, haz clic en instalar y el distribuidor se encarga. > [!NOTE] > Instalando un conector de canal fuera del conjunto principal (solo Telegram) > requiere un activo **Arrancador**, **Negocios** o **Empresa** licencia. > En el plan Comunitario, tal solicitud devuelve **HTTP 402 "actualización requerida"** > (código `plan_limit`) — ver [Licenciamiento](/es/v1.0/commercial/licensing). > [!NOTE] > la **Einstein** el complemento de memoria es **incorporada**: se instala automáticamente, > lleva una insignia "Incorporada" y no puede ser eliminada ni detenida. ## El flujo de SystemdDeployer Bajo el capó el **DesplegadorSystemd** realiza estos pasos: 1. **Descargar un archivo tar** para el complemento seleccionado. 2. **Ejecuta el manifiesto `install[]` pasos** declarado por el complemento. 3. **Renderizar una unidad systemd en un entorno aislado** para el complemento. 4. **Encuesta `/healthz`** hasta que el servicio informe que está saludable. ```text download tarball ─▶ run install[] steps ─▶ render sandboxed systemd unit ─▶ poll /healthz ─▶ active ``` Solo cuando `/healthz` solo se considera instalada si la instalación se marca como activa: un complemento que no se inicia no se considera instalado de manera silenciosa. ## Systemd nativo del host, en sandbox — no Docker Cada complemento se ejecuta como **su propio servicio systemd aislado**. No hay contenedores, no hay Docker, no hay orquestador: un plugin es un servicio de Linux gestionado con su propia unidad, puerto y restricciones de sandbox, supervisado por systemd como el resto de la instalación. > [!WARNING] > AiHummer es nativo del host. Los plugins se implementan como servicios systemd en sandbox > desde un paquete tar de lanzamiento — **nunca como contenedores de Docker.** Si un guía te dice > para "ejecutar el contenedor del complemento", no describe a AiHummer. ## Control de salud con /healthz El desplegador consulta el plugin `/healthz` punto final antes de declarar el éxito. Esta puerta de salud es lo que hace que la instalación con un solo clic sea segura: un complemento roto o mal configurado se detecta durante la instalación en lugar de descubrirse más tarde en producción. ## Actualización automática por instalación Las actualizaciones se manejan **por instalación**. Cada plugin instalado puede actualizarse automáticamente según su propio calendario, por lo que mantener los plugins actualizados no requiere una reinstalación manual cada vez que una nueva versión llega al catálogo. Los mismos pasos de descargar → instalar → unidad de render → verificación de estado se aplican a una actualización como a una instalación inicial. > [!TIP] > Debido a que la actualización automática es por instalación, puedes mantener algunos complementos fijados mientras > permitiendo que otros sigan lo más reciente: cada instalación gestiona su propio ciclo de vida. ## Catálogo de múltiples fuentes El catálogo ya no está vinculado a una sola URL. El **catálogo comunitario** de complementos de terceros se incluye como incorporado **fuente predeterminada** (instalado con semillas) — no lo añades tú mismo. En **Complementos → Fuentes** (Interfaz de administrador, o `POST /v1/admin/modules/catalog/sources`) puedes agregar tus propias fuentes adicionales. La puerta de enlace sincroniza cada fuente habilitada al iniciar y en el intervalo de actualización automática. - la **fuente oficial** (los módulos de primera parte) están fijados y confiables por defecto — un objeto separado que es **no sobrescrito** por otras fuentes. - la **catálogo comunitario** es una fuente predeterminada con semilla; **fuentes privadas** son añadido por el operador. Cada entrada del catálogo tiene un `origin`, y eso `origin` decide qué ancla se verifica la firma contra (oficial → clave fijada, privada → almacén de confianza). Para publicar en el catálogo de la comunidad, consulte [Publicando un complemento](/es/v1.0/marketplace/publishing). ## Modelo de confianza y la clave fijada La instalación verifica la firma de un complemento por su origen: - **oficial** → verificado contra el **clave de registro fijada en el núcleo**. Confiado por predeterminado, sin acción del operador. - **privada** (carga lateral) → verificado contra el **almacén de confianza de la instancia**; el La clave del autor es aprobada por el operador al subir (un clic). - **sin signo** → rechazado, excepto en modo de desarrollo (`AIHUMMER_PLUGIN_DEV_UNSIGNED=1`, solo desarrollo local). > [!WARNING] > **Los plugins de la comunidad no se pueden instalar ahora mismo — y no es un > problema de conexión.** La clave con la que se firmaba el catálogo comunitario > ha sido retirada; hasta que llegue una clave nueva, la verificación de firma > rechaza esas entradas. Aparte de eso, el código de terceros todavía no se > ejecuta como servicio en su servidor: hasta que exista un entorno de ejecución > aislado solo se admiten integraciones que funcionan en su propio lado y se > conectan por la red. > > **Qué verá:** tras pulsar «instalar» aparece el mensaje habitual «instalando», > pero el plugin **nunca aparece** en la lista de instalados. El motivo del > rechazo queda en el registro de la pasarela — abra **Registros** en el panel de > administración. > > **Qué sí funciona hoy:** > > - **los plugins de AiHummer** del catálogo oficial — se instalan como siempre, > llevan otra firma, válida; > - **un servidor MCP por HTTP** — conectado como fuente de herramientas sin > desarrollo, el código se queda en su lado; > - **una integración por especificación OpenAPI** — lo mismo, sin servicio que > instalar. > > La carga lateral de un plugin propio supera la verificación de firma, pero solo > se ejecutará como **MCP remoto por HTTP** o integración OpenAPI; una compilación > que deba arrancar como servicio en este mismo servidor se rechaza. ## Actualizaciones firmadas Una actualización **vuelve a ejecutar la misma puerta de firma** como la primera instalación: al pasar a una nueva versión, la firma se verifica nuevamente contra el mismo ancla de confianza. Una actualización **no se puede omitir** el cheque — no puedes elevar la confianza mediante una actualización. ## La placa y clasificación oficial En el catálogo de la interfaz web, los complementos de AiHummer llevan un **Oficial** insignia y rango primero. Los complementos de terceros se muestran sin insignia y se ordenan **por número de descargas**. La bandera oficial se deriva de la entrada de un participante `origin` (oficial) — no se puede establecer manualmente en el manifiesto. ## ¿A dónde vamos ahora? - [Resumen del mercado y niveles](/es/v1.0/marketplace/overview-tiers) — qué diablos tres niveles de complementos son. - [SDK de complementos](/es/v1.0/marketplace/sdk) — el `manifest.json` cuya `install[]` pasos que este ciclo de vida ejecuta. - [Publicando un complemento](/es/v1.0/marketplace/publishing) — carga lateral privada y publicación comunitaria a través del gabinete personal. - [Integraciones sin código](/es/v1.0/marketplace/zero-code) — agregar herramientas OpenAPI/MCP sin servicio que instalar.