KairosLink
Instalar el agente Linux
Cómo instalar el agente en un servidor Linux con una línea de comando, qué requisitos tiene, qué módulos funcionan y en qué se diferencia del agente Windows.
En Linux no hay instalador que descargar ni build que esperar. El panel te da una línea de comando, la pegás en el servidor y listo.
Esta guía cubre la instalación, la verificación, el diagnóstico y, sobre todo, qué hace y qué no hace el agente Linux comparado con el de Windows. Eso último es lo que define qué le podés prometer a un cliente con servidores Linux.
En qué se diferencia del agente Windows
Si venís de instalar el agente en Windows, esto es lo que cambia:
| Windows | Linux | |
|---|---|---|
| Qué se entrega | Un archivo MSI de unos 17 MB | Una línea de comando |
| Cómo se produce | Build por cliente, 30 a 90 segundos | Ya está publicado, se entrega al instante |
| Vencimiento | 7 días | No vence |
| Personalización al generarlo | Nombre, sitio, departamento, tipo | Ninguna |
| Arquitecturas | 32 y 64 bits | Solo x86_64 |
| Requisito duro | Windows | systemd |
| Despliegue masivo | Por GPO desde el panel | Con tus propias herramientas |
| Actualización desde el panel | Sí | No |
| Control remoto | Sí | No; en Windows y macOS sí |
Obtener el comando
En Clientes, ficha del cliente, pestaña Equipos, tarjeta Instalador, botón Crear Instalador. Necesitás permiso de gestión de equipos.
En el modal, solapa Linux. Esa solapa no tiene campos que completar: muestra el comando y nada más. Botón Copiar comando.
El comando tiene esta forma:
curl -fsSL https://app.kairoslink.io/install/TOKEN | sudo bash
El token va en la URL, no dentro de un archivo. Es la credencial de enrolamiento de ese cliente, la misma que usa el MSI de Windows. Trátalo como una contraseña: quien lo tenga puede sumar equipos a ese cliente.
El comando no vence. A diferencia del MSI, que muere a los 7 días, esta línea sirve mientras la credencial del cliente siga activa. Podés guardarla en tu documentación interna y reutilizarla.
Requisitos
Cuatro, y el script los verifica en este orden:
- Root. No es negociable: el
sudodel comando está por algo. - systemd. Es el requisito duro. Sin systemd el agente no se instala.
- Arquitectura x86_64. No hay agente para ARM. Si administrás servidores ARM, hoy no están cubiertos.
- Distribución reconocida. Se validan las principales familias: Debian y derivadas, Red Hat y derivadas, SUSE.
Si tu distribución no está en la lista pero cumple los otros tres requisitos, se puede forzar la instalación con --forzar-distro. Funciona, pero queda fuera de lo verificado.
Salida a internet por 443 hacia el panel. Como en Windows, el agente inicia todas las conexiones hacia afuera: no hace falta IP pública ni abrir puertos de entrada.
El binario es estático (musl): no depende de la glibc de la distribución, así que no hay dependencias que instalar ni conflictos de versión. Se publica desde GitHub Releases, pero el equipo no necesita alcanzar GitHub: el panel proxea los archivos del agente, así que la descarga sale siempre del dominio de KairosLink, igual que en Windows y en macOS.
Si el servidor sale por proxy
Hay una trampa que conviene conocer: el primer curl corre como tu usuario, pero las descargas de adentro del script corren bajo sudo, que limpia las variables de entorno.
Si el servidor necesita proxy, usá sudo -E para que las variables se conserven.
Instalar
Pegás el comando en la terminal del servidor y se ejecuta solo. El script verifica los requisitos, descarga los archivos, valida su integridad, escribe la configuración, instala el servicio y lo arranca.
Una instalación buena termina así:
[ OK ] El servicio io.kairoslink.agent.service esta ACTIVO
[ INFO ] El equipo deberia aparecer en el panel en menos de un minuto.
[ INFO ] Fingerprint de este equipo: ...
Guardá ese fingerprint. Es el mismo valor que queda registrado en el panel, así que es la forma más directa de cruzar un servidor físico con su fila en la lista de equipos.
Si el servicio no queda activo, el script muestra el estado y 40 líneas del log, y termina con error.
Opciones útiles
El instalador acepta parámetros. Los que más se usan:
| Opción | Para qué |
|---|---|
--forzar-distro |
Instalar en una distribución no verificada |
--version-agente |
Clavar una versión concreta en vez de la última |
--local |
Instalar desde archivos ya presentes, sin descargar |
--help |
Ver todas |
Instalar sin salida a internet
Si el servidor no llega al panel, el modal tiene un menú Archivos del agente con las URLs directas.
Bajás los cuatro archivos, los dejás todos en la misma carpeta del servidor, y corrés:
chmod +x install.sh
sudo ./install.sh --token TOKEN --local
El chmod hace falta porque la descarga por HTTP no conserva el bit de ejecución.
Instalación masiva
El panel no tiene herramienta de despliegue masivo para Linux. No hay equivalente al despliegue por GPO de Windows.
La línea de curl | sudo bash es apta para meter en Ansible, en cloud-init o en un bucle de SSH, pero eso lo armás vos con tus propias herramientas y el panel no deja registro de la campaña.
Qué queda instalado
| Ruta | Qué es |
|---|---|
/usr/local/bin/kairoslink-agent |
El binario |
/usr/local/bin/kairoslink-agent-uninstall.sh |
El desinstalador |
/etc/systemd/system/io.kairoslink.agent.service |
El servicio |
/etc/kairoslink/agent.conf |
Endpoint y token |
/var/lib/kairoslink/ |
Identidad del equipo |
El servicio se llama io.kairoslink.agent y arranca con el equipo.
Las rutas no son configurables: están compiladas dentro del binario.
Un detalle de seguridad que importa: agent.conf contiene el token de enrolamiento del cliente en texto plano, protegido con permisos 0600. Un backup del /etc de ese servidor se lleva la credencial del cliente entero. Tenelo en cuenta al armar tus backups.
Verificar
En el servidor:
systemctl is-active io.kairoslink.agent
journalctl -u io.kairoslink.agent -f
En el panel, pantalla Equipos. Como en Windows, lo que confirma que está vivo es la columna Última conexión, no que la fila exista.
Qué hace y qué no hace
Esto es lo que define qué le podés vender a un cliente con servidores Linux.
Lo que funciona
- Monitoreo de recursos y alertas, con uso de disco por sistema de archivos
- Parches con apt y dnf: selección, todos, o solo seguridad, con progreso en vivo, historial y reinicio programado
- Control de las actualizaciones automáticas de la distribución, configurable por cliente desde Clientes, Equipos, tarjeta de control de parches. Este ajuste es exclusivo de Linux: en Windows el parcheo lo maneja Windows Update
- Consola de comandos en bash, con asistencia de IA que trabaja en bash y rechaza PowerShell
- Servicios como unidades systemd, procesos, tareas de cron y timers, aplicaciones y explorador de archivos
Lo que no está
- Control remoto. No hay escritorio remoto para Linux. Sí lo hay en Windows y en macOS
- Actualización desde el panel. El agente Linux se actualiza corriendo el comando de instalación de nuevo, no despachándolo desde la pantalla de Agentes
- Despliegue masivo desde el panel
- Paquete nativo. No hay
.debni.rpmni repositorio: el agente no aparece en el gestor de paquetes - ARM
Pestañas que no aparecen en un equipo Linux
Seis pestañas se ocultan porque no tienen equivalente honesto:
| Pestaña | Por qué |
|---|---|
| Inicio | No hay equivalente real; lo más cercano son las unidades systemd habilitadas, que ya se ven en Servicios |
| Registro | No existe registro en Linux |
| Impresoras | El equivalente sería CUPS, con un modelo de datos distinto |
| Certificados | No existe el almacén de certificados de Windows |
| Bloqueos de cuenta | Es de Active Directory |
| Nivel funcional | Es de Active Directory |
Una trampa que hay que conocer
El agente Linux corre dentro de un entorno endurecido de systemd, y todo lo que ejecuta lo hereda. Entre otras cosas, ve /usr en modo solo lectura.
Consecuencia práctica: un comando que instale paquetes lanzado desde la consola del panel puede fallar con un error de sistema de archivos de solo lectura que no menciona systemd por ningún lado. Lo mismo con comandos que necesiten escribir dentro del home de un usuario.
El módulo de parches sí instala paquetes y funciona: eso está resuelto por otra vía. Lo que puede fallar es un comando manual que escriba en esas rutas.
Si venís de Windows, esto es lo que más te va a sorprender: comandos que fallan por razones que no están en el comando.
Cuando no aparece
El comando devolvió un error y no instaló nada. El script es explícito: te dice si falta root, si falta systemd, si la arquitectura no es x86_64 o si la distribución no está en la lista. Leé el mensaje.
El instalador dijo OK, el servicio está activo y el equipo no aparece. Mirá el log con journalctl -u io.kairoslink.agent -f. Las causas son las mismas que en Windows: token rotado, cliente borrado, tope del plan alcanzado, o el servidor sin salida al panel por 443.
El equipo aparece pero el panel lo trata raro. Verificá que el sistema operativo se haya detectado bien en la ficha.
Reinstalar
Reinstalar sobre una instalación existente no duplica el equipo: se reconoce por su huella de hardware, y además /var/lib/kairoslink conserva la identidad.
El propio script te avisa cuando detecta que es una reinstalación.
Para actualizar el agente, corré el mismo comando de instalación otra vez. No uses la pestaña Agentes del cliente: esa pantalla trabaja con el instalador de Windows.
Desinstalar
En el servidor:
sudo /usr/local/bin/kairoslink-agent-uninstall.sh
Si querés conservar la identidad del equipo para reinstalarlo después sin que aparezca como uno nuevo, existe la opción --conservar-estado.
Del lado del panel, el equipo se comporta igual que en Windows: si el agente alcanza a avisar, desaparece de la lista; si no, queda en Offline y lo sacás con Quitar de la lista.
Preguntas frecuentes
¿Necesito generar algo antes de instalar? No. El comando ya existe, se copia y se pega.
¿El comando vence? No. Sirve mientras la credencial del cliente siga activa.
¿Sirve el mismo comando para varios servidores del mismo cliente? Sí, sin límite de tiempo.
Tengo servidores ARM. Hoy no están cubiertos. El agente es solo x86_64.
Mi distribución no está en la lista.
Si tiene systemd y es x86_64, probá con --forzar-distro. Queda fuera de lo verificado, pero funciona.
¿Puedo tomar control remoto de un servidor Linux? No. Hoy el control remoto funciona en Windows y en macOS; en Linux no.
¿Cómo actualizo el agente Linux? Corriendo el comando de instalación de nuevo. La pantalla de Agentes no despacha actualizaciones a Linux.
Un comando de la consola falla con "read-only file system".
Es el endurecimiento de systemd: el agente ve /usr en solo lectura y lo que ejecuta lo hereda.
¿Hay un .deb o un .rpm? No. La instalación es por script y el agente no figura en el gestor de paquetes.
¿Puedo instalarlo con Ansible? Sí. La línea de comando es apta para eso, pero el panel no ofrece la herramienta ni registra la campaña.
Actualizado el 22 de agosto de 2026