Nombra una plataforma y yo te nombro su gestión de dispositivos. ¿Windows? Microsoft Intune — y antes SCCM, hoy MECM, que nadie pronuncia con seguridad. ¿macOS? Jamf — tan dado por sentado que los administradores de Mac no sabrían actuar de otra manera. ¿iPhone y iPad? MobileIron, MaaS360, Workspace ONE — todo un zoológico de soluciones MDM, todas hablando el mismo protocolo de Apple. ¿ChromeOS? La consola de Google Admin, elegante hasta el aburrimiento. ¿Android? Ningún problema: toda flota Knox, toda tarifa de operador trae la gestión integrada.

¿Y Linux?

Silencio.

Ese silencio es la tesis de este texto: el sistema operativo que sostiene la infraestructura más exigente del mundo — bancos, telecomunicaciones, hospitales, industria — es el mismo para el que nadie ha construido seriamente una gestión de dispositivos para el escritorio. No comercialmente. No libremente. En ninguna parte con la seriedad que Jamf aporta a Apple.

No es vergonzoso. Es una oportunidad.

Qué es realmente la gestión de dispositivos

No nos esconderemos tras palabras de moda. La gestión de dispositivos es una disciplina de contornos definidos. Un dispositivo se inscribe. Recibe políticas — qué se permite, qué es obligatorio, qué se prohíbe. Recibe software — automáticamente, en silencio, sin que el usuario busque. Se inventaría — quién tiene qué dispositivo, en qué estado, en qué revisión. Se actualiza — dirigido centralmente, no dejado a la buena voluntad del usuario. Se vigila — ¿está en línea, sano, cumplidor? Y algún día se retira — seguro, limpio, con todo lo que ello implica.

Todo ello envuelto en una interfaz tan evidente que un administrador dirige flotas de mil dispositivos sin pensar por equipo. Apple fijó ese listón con la app Self Service de Jamf: el usuario ve una app, toca, ahí está. Coherente. Amable. Ordenado.

Con esa vara medimos. No con una menor.

El mercado que existe

Miremos con honestidad. Los productos comerciales no son malos — triunfan porque entregan.

En el campo de Windows reina Intune, nativo de nube, MDM por protocolo, desplazando cada vez más al clásico SCCM/MECM, que llega on-premises y ligado a un agente con su propio encanto pesado. Ambos juntos — co-management — son la realidad en muchas casas.

Para Apple, Jamf es el estándar, flanqueado por jóvenes contendientes — Kandji, Mosyle, Addigy — todos nacidos en la nube, todos exclusivamente Apple. Gestiona Macs en una empresa y apenas escapas de este ecosistema.

Encima se sienta lo que hoy se llama Unified Endpoint Management: Workspace ONE (antaño AirWatch, actualmente bajo Omnissa), MaaS360 de IBM, Ivanti (que unió MobileIron y Pulse Secure), ManageEngine Endpoint Central, Hexnode. Cada uno intenta gestionar todo — Windows, Mac, móvil, a veces Linux servidor, raramente el escritorio Linux. Y ChromeOS reina en la consola de Google Admin, sencillamente ideal para Chromebooks.

El hilo común: este mundo gira en torno a Windows, Apple y móvil. El escritorio Linux es en él una nota al pie — si acaso se menciona.

El punto ciego extraño

Aquí se vuelve interesante. Nada comparable existe para el escritorio Linux.

Canonical ofrece Landscape — pero gestiona Ubuntu, principalmente servidores, y fino en profundidad. SUSE Manager reposa en Salt, concebido cerca de la infraestructura. Foreman con Katello aprovisiona y configura, pero su latido está en la sala de servidores, no en el escritorio. osquery, apareado con Fleet, entrega visibilidad y cumplimiento — pero interroga el estado, no lo declara. Chef y Puppet llevan ADN de servidor; pueden alcanzar el escritorio, pero nadie les enseñó cómo se siente Jamf.

Ninguno entrega lo que arriba puse como vara: una experiencia de gestión que tome el escritorio en serio — perfiles, asignación de aplicaciones, preferencias de usuario, apps por defecto, manejadores MIME, disposiciones de pantalla — y la envuelve en una interfaz que sea un placer.

No es queja. Es diagnóstico. El hueco existe porque Linux no pertenece a nadie — luego nadie construye un producto que vender para él. Pero precisamente por eso podemos cerrarlo nosotros mismos.

De vuelta al código abierto, a la dura

Se podría esperar a que un proveedor notara el hueco. Se podría comprar un UEM propietario y esperar que tomara en serio a Linux algún día. Ambas son irreales. Quien espera a sus proveedores externaliza la definición de su propia herramienta — y con ella la soberanía sobre su propia flota.

Así que lo construimos. Abierto. Con Ansible como cimiento, una base relacional como fuente de verdad y un plugin que conecta ambas. A la dura — porque la dura es la única vía donde de verdad entiendes lo que construyes.

Por qué Ansible es el cimiento

No necesito explicar Ansible en extensión aquí. Sin agente, SSH, idempotente, declarando estado en lugar de procedimiento — en otro sitio lo defendí. Para la gestión de dispositivos aun cabe nombrar: es la única automatización extendida que no presupone un demonio gestionado corriendo en el destino. Una caja que habla SSH es gestionable. Punto.

Pero Ansible es el cimiento, no el techo. Declara estado maravillosamente — no lo modela. Y ahí empieza el problema real.

Donde YAML alcanza sus límites

Una flota pequeña tolera YAML. Diez cajas, un inventario, unas variables de grupo — listo. Pero una flota real no es lineal. Es una urdimbre de dispositivos, propietarios, roles, perfiles, sitios, departamentos, excepciones, lotes de aplicaciones y fragmentos de configuración, todos relacionados. La misma app en tres tipos de perfil, pero sólo en dos sitios, salvo aquel dispositivo que merece un caso especial.

Las anclas y alias de YAML son bonitos. No sustituyen a la integridad referencial, los joins, las restricciones, la normalización y las transacciones. Un inventario plano de YAML se doblega bajo su propio peso en cuanto la matriz dispositivos × perfiles × excepciones pasa a tres dimensiones.

Esto exige una base relacional de verdad. PostgreSQL. Con un esquema pensado: dispositivos, propietarios, clases de perfil, aplicaciones, fragmentos de configuración, sitios, concesiones de excepción, estado de inscripción. Claves foráneas que imponen relaciones. Vistas que responden preguntas complejas en una sola consulta. Y un plugin de búsqueda escrito por uno mismo que traduce esas filas, en tiempo de ejecución, a variables que Ansible entiende — relaciones que devienen plantillas Jinja2.

La verdad vive en un lugar. Las plantillas derivan de relaciones, no de copias. Esa es la diferencia entre un inventario y un modelo.

Por qué no simplemente extender NetBox

Una objeción justa — y la conozco, pues mi propia caja de herramientas ya incluye roles de NetBox. NetBox es, en esencia, lo que acabo de describir: PostgreSQL debajo, una interfaz web encima, un sistema de plugins, campos personalizados, etiquetas, relaciones, REST y GraphQL. Una fuente única de verdad, querida por los de redes, con razón.

Pero NetBox tiene un marco — DCIM e IPAM — y su mantenedor lo custodia con un rigor envidiable. Las peticiones que no encajan en la imagen de red y centro de datos caen rutinariamente por la criba. No es un defecto. Es la razón por la que NetBox sigue excelente en lugar de proliferar.

El ciclo de vida del escritorio, sin embargo, es otro dominio. Asignación de perfiles, lotes de aplicaciones, preferencias de usuario, MIME por defecto, disposiciones de pantalla, estado de inscripción — no se modela de forma natural sobre inquilinos, sitios, racks y VLANs. Quedan dos caminos: un esquema autónomo, construido para el escritorio, que con el tiempo se dote de su propia interfaz web. O un plugin de NetBox que aporte los modelos de escritorio sin tocar el núcleo. Ambos legítimos. Apostar a la aceptación en el núcleo aguas arriba sería ingenuo. Mi instinto dice: primero la verdad autónoma, construida a propósito — y si los dominios se reconcilian algún día, migrarla como plugin adonde pertenece.

La interfaz web que llegará algún día

Lo admito abiertamente: al principio no hay portal brillante. Hay SQL, la línea de comandos y el plugin. Basta para quien construye — y para quien sabe lo que hace. Pero la gestión de dispositivos debería algún día ser manejada por gente que prefiere no leer YAML. Así que la interfaz web llega a su debido tiempo: CRUD sobre el esquema, asignación de perfiles arrastrar-y-soltar, una vista por dispositivo, una por usuario, una por flota. Hasta entonces el esquema es la verdad — y la verdad está bastante bien estructurada para que cualquier interfaz futura simplemente se aposente sobre ella.

Todo en archivos — por qué Linux está predispuesto

Ahora el punto arquitectónico más profundo, y es la palanca real.

Linux se configura en archivos. Dotfiles en el directorio personal. /etc para el sistema. Unidades de systemd como texto. Manejadores MIME como texto. Foot, Kitty, Waybar — texto. Y Sway, el gestor de ventanas en mosaico que despliego mediante mi propio rol de Ansible: configuración puramente textual. Quien haya sentido un cambio de modo, una pantalla completa, un mosaico encajar con una combinación de teclas entiende por qué no es sólo eficiente — es hermoso. Casi mágico. De golpe una ventana se desliza, otra se mosaiciza junto y todo encaja — sin ratón, sin menú.

No me detendré mucho en Sway. El punto es mayor. En GNOME, los ajustes viven en dconf — un almacén de afinidad binaria que cede al temple sólo de mala gana. KDE usa ficheros tipo ini, pero con sus rarezas en torno a kded y kwriteconfig. Sway, en cambio, es texto puro — y el texto puro es territorio Jinja2. Un rol, una plantilla, un renderizado — hecho. Precisamente por eso la pila Sway/Wayland atrae tanto a Ansible: todo lo definido es un archivo, y cada archivo es una plantilla.

No es casualidad. Es la condición arquitectónica que Linux aporta a la gestión de dispositivos y que los sistemas propietarios ofrecen sólo en parte.

La caja de herramientas Manage-My-Network

No argumento desde la teoría. Bajo imp1sh en GitHub yace mi colección de Ansible ansible_managemynetwork — abierta, orientada a Debian y OpenWrt, crecida a lo largo de los años. Entre sus roles: Sway y Waybar, pero también agente de Zabbix, SNMPD, Restic y Borgmatic para copias, parcheo, claves SSH, usuarios y grupos, MOTD, Chrony, DNS, cortafuegos. La prueba: el patrón funciona. Nada teórico. Todo desplegado — a menudo bajo presión.

Esta colección es la semilla. La gestión de dispositivos que aquí bosquejo es el árbol.

Amor al detalle — mejor que Apple

Ahora resulta presuntuoso. Ahora se vuelve honesto.

No hablamos de replicar funcionalidad. Hablamos de superar la experiencia. Coherente, amable, ordenado — como Apple lo inauguró, pero sin paternalismo. Valores por defecto que respetan al usuario. Una flota tan fácil de gobernar que un admin dirige mil dispositivos sin pensar por equipo. Integración de monitorización que crece a la par: cada dispositivo despliega automáticamente su exportador de nodo, su agente de Zabbix, su SNMPD — la flota se vuelve observable sin que nadie inscriba nada a mano.

El proyecto real no es inventar una distribución. Es afinar continuamente una publicación existente. Pulido. Una y otra vez. De forma tan constante que al final nadie desea sinceramente volver a macOS o Windows. Jaja — pero en serio.

La decisión de la distro

¿Qué publicación? Aquí se vuelve concreto y no pienso esquivar.

Debian es el ancla natural — mi colección lo tiene como objetivo, es sólido como roca, y esa constancia es un regalo para una flota que merece estabilidad. El precio: estable puede ser demasiado prudente para un escritorio lustroso. El remedio es pragmático — backports, Flatpaks para aplicaciones actuales, selectivamente testing. No dogma, mezcla.

Fedora es la tentación: Wayland más fresco, Sway al día, PipeWire al corriente, cercano al upstream. Quien quiera un escritorio vivo encuentra poco que reprochar. El precio es una cadencia más alta — agitación que puede fatigar a una flota si no se cuida.

openSUSE y derivados Arch también están en la sala; NixOS es intelectualmente tentador pero, en mantenimiento, una lengua aparte. Saldo honesto: para pulido continuo sin incendios, Debian es el suelo donde más tranquilo se construye. Fedora queda como prueba para quienes prefieren frescura a calma. Me inclino por Debian — y lo digo abiertamente, porque la colección ya lo eligió.

Integración que crece a la par

Una flota que se inscribe a sí misma sólo está a medio hacer. La otra mitad es observabilidad. En cuanto un dispositivo se incorpora, recibe su exportador, su agente, su configuración de copias — todo del esquema, todo con plantilla. Prometheus raspa, Zabbix registra, Uptime Kuma hace ping. Las copias corren con Restic o Borgmatic — cifradas, deduplicadas, sin que nadie piense en ellas. La retirada se hace limpia: claves fuera, inventario archivado, monitorización silenciada. Todo el ciclo de vida, cableado.

Cómo funciona de verdad la inscripción — honestamente

Para que no sea ilusión: Ansible empuja por defecto — controlador a host por SSH. Los portátiles nómadas rara vez son alcanzables cuando hace falta. Luego modo pull. ansible-pull, movido por un temporizador de systemd o cron, tira periódicamente del estado declarado desde el repositorio. Un controlador ligero — AWX o un pequeño runner — coordina lo pendiente. La inscripción se reduce a: un dispositivo, un token, un primer pull. Sin brujería. Sólo consecuencia.

Es más honesto que la promesa de los check-ins MDM clásicos — y para una flota de código abierto, suficientemente robusto.

Por qué esto tiene sentido

Alguien podrá preguntarse: ¿estáis reconstruyendo Jamf para Linux? Sí y no. Sí, porque la aspiración es la misma — gestión de flota que toma el escritorio en serio. No, porque el camino difiere: no un producto que compras, sino un modelo que posees. Código abierto, relacional, guiado por texto, con amor al detalle.

El hueco existe porque Linux no pertenece a nadie. Precisamente por eso podemos cerrarlo — sin permiso, sin la hoja de ruta de otro, sin miedo a que un proveedor corte el enchufe. No es un inconveniente. Es la condición de posibilidad.

Si gestionas una flota de escritorios Linux — o planeas una — y te has preguntado cómo ha de funcionar sin apoyarse en un UEM propietario: hablemos. Sin presión comercial, con la vista en el largo plazo. Escribe a contact@libcom.de. Haremos inventario — honesto, trazable — y pensaremos juntos si y cómo este enfoque conviene a tu flota.