FleetDM en concesionarias: inventario, parches y salida
Caso de industria para ordenar endpoints con FleetDM y osquery: inventario, políticas, scripts, permisos, costos y respaldo.
Notebook de ventas, PC de taller, caja administrativa: si el inventario llega tarde, el parche también llega tarde. FleetDM usa osquery y políticas para listar equipos, software, usuarios y estado de seguridad en Windows, macOS y Linux. En una concesionaria sobre Ruta 40 en Tunuyán, la nota muestra cómo armar un caso mínimo con inventario, scripts, permisos, respaldo y salida ordenada.
Dónde el inventario deja de servir como foto vieja
El caso parte de 37 equipos repartidos entre salón, taller, administración y repuestos. La planilla de compras tenía número de serie, proveedor y fecha de factura. Faltaban sistema operativo, usuario activo, versión de navegador, cifrado de disco y parches pendientes. FleetDM convierte esos datos en inventario vivo, porque el agente reporta estado y permite consultar equipos con preguntas repetibles.
La cifra que corrige el calendario es reciente: Fleet v4.86.0 fue publicado el 29 de mayo de 2026, y el proyecto mantiene su código en GitHub con documentación abierta. La capa de consulta viene de osquery, que expone Linux, macOS y Windows como tablas consultables con SQL. Para una concesionaria, esa combinación evita que inventario y seguridad vivan en archivos distintos.
La calcomanía plateada decía CPU 14; el sistema veía otro nombre.
El antagonista era un inventario de compras sin fecha de uso. El puente global lo muestra el propio modelo de Fleet: su sitio explica el enfoque open source y self-hosted, con configuración que puede vivir en Git y gestión de endpoints auditables. La lectura local es concreta: si el endpoint tiene acceso a sistemas de ventas, caja o garantías, compras necesita saber qué existe, aunque sistemas necesita saber qué cambió.
Cómo funciona por dentro
El flujo empieza con el enrolamiento. Fleet entrega un secreto o instalador; el endpoint instala fleetd y osquery, se registra contra el servidor y envía información de hardware, sistema operativo, software y usuario. Fleet guarda hosts, políticas, consultas, equipos y resultados en MySQL. Redis sostiene colas y tareas. El servidor muestra estado por equipo, etiqueta, política y vulnerabilidad, según la arquitectura documentada por Fleet.
Las políticas son consultas con resultado esperado. Un equipo cumple si tiene cifrado activo, versión mínima de navegador o agente de respaldo presente. Los scripts permiten acciones acotadas: consultar un servicio, listar software o ejecutar una corrección aprobada. Fleet guarda estado técnico del endpoint y evidencia de consulta. Los documentos del cliente siguen en ERP, CRM o almacenamiento interno.
Los permisos separan lectura, ejecución y administración. Compras ve inventario y antigüedad. Sistemas ejecuta consultas y scripts. Seguridad revisa políticas y exporta evidencia. Gerencia consulta tablero por sede. El backup copia MySQL, configuración, certificados y secretos de enrolamiento; la prueba de restauración levanta Fleet en otro servidor y confirma que un endpoint piloto vuelva a reportar con sus políticas intactas.
Qué se instala o configura primero
La pila mínima usa FleetDM, MySQL, Redis, proxy HTTPS, backup con Restic y un repositorio Git privado para políticas y configuración. En cada equipo se instala fleetd. Un despliegue inicial cuesta entre USD 20 y USD 75 mensuales de infraestructura, entre ARS 28.640 y ARS 107.400 al dólar vendedor oficial de ARS 1432. Ese monto cubre servidor, almacenamiento y monitoreo. Licencias de sistemas operativos, antivirus comercial y horas de soporte de endpoints se calculan por separado.
El primer entregable verificable es una vista de 20 equipos con nombre, usuario, sistema operativo, serial, software crítico y último contacto. El segundo es una política con resultado medible: disco cifrado, navegador actualizado o backup activo. En un tablero UMSA, la prueba se aprueba cuando compras puede exportar inventario y sistemas puede demostrar qué equipo falla sin abrir sesión remota.
La implementación toma entre tres y cinco semanas. La primera define etiquetas por sede y área. La segunda instala agentes piloto. La tercera escribe políticas mínimas. Las siguientes conectan alertas, respaldo y reporte mensual. En la concesionaria, el cambio visible fue una lista de equipos fuera de norma pegada al cierre de compras. Esa lista nombró responsables sin frenar ventas. Cada excepción quedó con fecha de revisión y motivo escrito.
Dónde se rompe y cómo probarlo
El primer riesgo es enrolar equipos con nombres inconsistentes. La señal aparece cuando el tablero muestra duplicados o hosts sin área. La prueba cruza serial, usuario y etiqueta antes de contar el equipo como inventariado.
El segundo riesgo es ejecutar scripts sin control. La señal aparece cuando un operador puede correr acciones fuera de su sede o sin ticket. La prueba usa un rol de soporte y revisa alcance, registro y aprobación previa.
El tercer riesgo es confundir inventario con respaldo. La señal aparece cuando Fleet muestra un equipo activo, aunque sus archivos no tienen copia reciente. La prueba consulta presencia del agente de backup y restaura un archivo de muestra en un entorno separado.
El inventario sirve cuando compras, sistemas y gerencia pueden mirar el mismo equipo y ver la misma fecha.