Servidor (plataforma)Server (platform)

Versión de mantenimiento que corrige un error de confianza TLS del instalador PowerShell en redes donde Windows no puede actualizar sus certificados raíz. Sin migraciones, sin cambios en el agente.

Cambios en esta versión

• El instalador PowerShell agrega la raíz ISRG Root X1 (Let's Encrypt) al almacén de Windows si falta, antes de descargar el agente. Se verifica por huella y no se toca nada si ya estaba.
• Corrige el error «No se puede establecer una relación de confianza para el canal seguro SSL/TLS» al llamar a DownloadFile, que aparecía aunque el navegador del mismo equipo abriera la descarga sin problema.
• Preguntas frecuentes suma una entrada para ese error.

Lo que se verificó antes de publicar

Notas de actualización

• Los scripts PowerShell ya descargados antes de esta versión no incluyen la corrección: genéralos de nuevo desde Agentes → Instalar agente.
• No hay release de agente en esta versión. El despacho destructivo de Observer Erase permanece False en producción.

---

Documentación: README.md. Uso interno de BrainCorp.

Versión de mantenimiento con columnas nuevas en tres reportes del Gestor de reportes y el límite de conexiones del proxy aplicado en cada despliegue. Sin migraciones, sin cambios en el agente.

Cambios en esta versión

• Inventario de Agentes y Fecha de Instalación del Agente suman la columna Nº Serie, junto al nombre del equipo.
• Especificaciones de Equipos suma la columna Sitio (el establecimiento), junto al cliente.
• Las columnas que ya mostraban los tres reportes se mantienen sin cambios.
• Proxy: deploy-api.yml aplica el límite de descriptores de nginx en cada despliegue y lo sube en caliente si nginx ya corre, sin cortar agentes ni sesiones remotas.

Lo que se verificó antes de publicar

Notas de actualización

• deploy-api.yml recarga las plantillas curadas, así que los reportes nuevos quedan disponibles al desplegar, sin pasos manuales.
• No hay release de agente en esta versión. El despacho destructivo de Observer Erase permanece False en producción.

---

Documentación: README.md. Uso interno de BrainCorp.

Versión que pone los asistentes de IA (MCP) bajo control de la consola. El servidor MCP de la 1.4.20 viene encendido en toda plataforma; ahora un administrador decide desde la webUI si la plataforma lo permite y qué roles pueden usarlo. Dos migraciones aditivas, sin cambios en el agente.

Cambios en esta versión

• Interruptor global. Configuración global → Asistente IA → Permitir asistentes de IA (MCP) en esta plataforma. Encendido por omisión. Al apagarlo, toda llamada por MCP recibe 403 al instante, sin redeploy y también para superusuarios. Las claves de API siguen sirviendo para la API REST directa.
• Permiso RBAC «Usar asistentes de IA (MCP)». En el Gestor de permisos, marcado por omisión en los roles existentes y en los nuevos. Quitarlo corta el canal MCP de los usuarios del rol sin tocar sus claves. El alcance por cliente y sitio sigue siendo el del rol.
• Motivo visible en el asistente. Con el canal cerrado, el técnico ve por qué (plataforma apagada o rol sin permiso) y dónde se habilita.
• Instalación en toda plataforma. install.yml, upgrade.yml y deploy-api.yml instalan o actualizan el servicio observer-mcp y publican /mcp; mcp_enabled: false en el inventario lo excluye.

Lo que se verificó antes de publicar

Notas de actualización

• Correr las migraciones es parte del deploy-api de siempre. Ambas son aditivas y dejan el MCP encendido para la plataforma y para todos los roles.
• deploy-api.yml converge también el servidor MCP (servicio + location /mcp en nginx). El reverse proxy perimetral de cada plataforma debe dejar pasar /mcp.
• No hay release de agente en esta versión. El despacho destructivo de Observer Erase permanece False en producción.

---

Documentación: README.md. Uso interno de BrainCorp.

Versión con una capacidad nueva: asistentes de IA conectados a la flota. Un servidor MCP integrado permite que cada técnico consulte y opere Observer RMM en lenguaje natural desde el asistente que ya usa, con sus propios créditos y sus mismos permisos. Además, la auditoría muestra el origen de cada acción. Es un salto seguro desde la 1.4.19: sin migraciones de base de datos, sin cambios en el agente y con el servidor MCP encendido por defecto en toda plataforma.

Cambios en esta versión

• Servidor MCP integrado. Observer RMM habla MCP (Model Context Protocol, spec 2026-07-28), el estándar abierto para conectar asistentes de IA con herramientas. Se conecta desde Claude Code, VS Code (Copilot), Cursor, Claude Desktop o n8n. El modelo corre en el asistente del técnico, con sus propios créditos; el servidor no consume tokens de ningún proveedor. Guía de conexión por cliente en docs.observer.cl/functions/mcp/.
• Mismos permisos que en la consola. Cada llamada usa la clave de API del técnico (encabezado Authorization: Bearer) y hereda su rol, así que ve y hace lo mismo que en la consola. Revocar la clave corta el acceso en la siguiente llamada.
• Alcance acotado. Consultas (clientes, sitios, equipos, chequeos, parches pendientes, software, historial, alertas, auditoría) y acciones reversibles (notas, correr chequeos, modo mantenimiento, posponer/reanudar/resolver alertas, aviso al usuario), con máximo 10 equipos por llamada y límite de llamadas por minuto. Scripts, comandos, reinicios, parches, borrado, usuarios y claves, modo perdido y Observer Erase no se exponen.
• Auditoría con origen. Nueva columna «Origen» en Auditoría y en el detalle: las acciones hechas por un asistente muestran el cliente MCP y la herramienta usada.
• Encendido por defecto. Toda instalación y todo deploy (install.yml, upgrade.yml, deploy-api.yml) instala o actualiza el servidor MCP y publica /mcp. Una plataforma se excluye con mcp_enabled: false en su inventario.

Lo que se verificó antes de publicar

Notas de actualización

• El despliegue de la API y del frontend es el de siempre; deploy-api.yml ahora converge también el servidor MCP (servicio observer-mcp + location /mcp en nginx). El reverse proxy perimetral de cada plataforma debe dejar pasar /mcp hacia el host del API.
• No hay release de agente en esta versión.
• El despacho destructivo de Observer Erase (ERASE_DESTRUCTIVE_DISPATCH_ENABLED) permanece False en producción.

---

Documentación: README.md. Uso interno de BrainCorp.

Versión de mantenimiento y endurecimiento: sin funciones nuevas a la vista, junta mejoras de rendimiento del servidor, seguridad, exactitud de las alertas y limpieza del inventario de parches. Es un salto seguro desde la 1.4.18 —sin migraciones de base de datos y sin cambios en el agente—, pensado para bajar el uso de memoria de la consola en flotas grandes y cerrar un par de bordes de seguridad.

Cambios en esta versión

• Menos memoria del servidor al aplicar políticas. Cuando una política tiene muchos equipos, sitios o clientes en su lista de exclusiones, el servidor guardaba en caché mucho más de lo necesario (el detalle completo de cada equipo excluido), inflando la memoria de la consola. Ahora sólo cachea lo indispensable —las claves de caché pasan de megabytes a kilobytes—, sin cambiar en nada el comportamiento de las políticas. Se nota en instalaciones con flotas grandes.
• Correr scripts en el servidor exige un permiso dedicado. Ejecutar un script «en el servidor» (no en el equipo) es una acción privilegiada; ahora, además del interruptor global que ya existía, requiere un permiso RBAC específico del usuario. El mismo control se aplica al configurar una plantilla de alerta cuya acción —o su acción de resolución— corra un script en el servidor, para que no se pueda escalar por esa vía.
• Las alertas ocultas ya no aparecen en el panel. En el Resumen de alertas, las alertas marcadas como ocultas dejan de listarse en ambas vistas, quedando consistente con el conteo del tablero que ya las excluía.
• Plantillas de reportes en un entorno más acotado. El motor de reportes expone a las plantillas sólo la superficie pública de sus utilidades de fecha y expresiones regulares, reduciendo lo que una plantilla puede alcanzar. Los reportes existentes siguen funcionando igual.
• El inventario de Windows Update se limpia solo. Cuando un equipo reporta su lista de actualizaciones, el servidor ahora descarta los parches pendientes que Windows dejó de listar (superseded), para que el inventario y el conteo de «atrasados» no acumulen parches fantasma. Sólo poda lo que el equipo ya no reporta; nunca borra pendientes legítimos.

Lo que se verificó antes de publicar

Notas de actualización

• El despliegue es el de siempre: la API y el frontend por sus playbooks de Ansible. Esta versión no trae migraciones de base de datos.
• No hay release de agente en esta versión: la flota sigue en su versión vigente y no requiere ninguna acción.
• El despacho destructivo de Observer Erase (ERASE_DESTRUCTIVE_DISPATCH_ENABLED) permanece False en producción, igual que en la versión anterior.

---

Documentación: README.md. Uso interno de BrainCorp.

Esta versión suma a Observer Erase la primera acción sobre el equipo, y es deliberadamente no destructiva: recuperar archivos antes de borrar. Desde el caso de un equipo perdido o robado, un operador autorizado puede rescatar archivos del equipo —«recuperar antes de borrar»— por el mismo canal cifrado de la evidencia del modo perdido, con la gobernanza que el bloque de borrado exige. El borrado destructivo remoto sigue deshabilitado a la espera de la aprobación legal correspondiente.

Acompaña al agente v2.17.2, que ejecuta la recuperación en Windows, Linux y macOS. Contra un agente anterior, la orden se ignora sin romper nada; la recuperación se aplica cuando el equipo actualice.

Cambios en esta versión

• Recuperación de archivos desde el caso. Un panel dentro del caso permite designar rutas —archivos o carpetas— y lanzar la orden. Los archivos viajan por el canal cifrado del modo perdido, quedan cifrados en reposo y se listan y descargan desde el mismo panel.
• Permiso dedicado, separado del borrado. La recuperación se gobierna con un permiso propio —recuperar archivos—, apagado por omisión y separado de la capacidad de ordenar un borrado: recuperar no es destruir, así que no arrastra la doble confirmación ni la ventana de arrepentimiento, pero tampoco se hereda de poder marcar un equipo como perdido.
• Sólo desde un caso abierto. Una orden exige un caso perdido abierto para el equipo; no se puede lanzar desde el listado general. Todo queda en la auditoría que sobrevive al equipo.
• Simulacro en seco. Cada orden puede lanzarse en modo simulacro: el equipo reporta qué recuperaría sin subir nada, para validar el circuito de punta a punta antes de una recuperación real.
• Resistente a equipos sin conexión. Si el equipo está apagado o sin red, la orden queda en cola y se entrega al reconectar sin ejecutarse dos veces; si no vuelve dentro de una ventana configurable, expira sola. Hay un tope de tamaño y de número de archivos por orden.
• Retención con piso legal. Los archivos recuperados se conservan con un piso legal (mínimo 12 meses) y se purgan al vencer, sin borrar jamás el registro de auditoría ni su cadena.

Lo que se verificó antes de publicar

Agente

Esta versión sí trae release de agente: v2.17.2, que ejecuta la recuperación de archivos. La flota lo toma por la vía de actualización habitual (ver las notas del agente).

Notas de actualización

• El despliegue es el de siempre: la API y el frontend por sus playbooks de Ansible. Esta versión agrega tablas nuevas (orden de recuperación y archivos recuperados) y un permiso; la migración corre con el despliegue de la API, sin pasos manuales.
• El borrado destructivo remoto sigue deshabilitado a propósito: la recuperación es no destructiva y no lo requiere.

---

Documentación: README.md. Uso interno de BrainCorp.

Esta versión estrena Observer Erase, el módulo de borrado y baja de activos del producto. En este primer incremento llega la parte que ya entrega valor sin tocar ningún equipo: certificar el borrado o la destrucción de un activo y custodiar su ingreso a proceso de baja, con la gobernanza que exigirá cualquier borrado futuro. El borrado destructivo remoto del equipo queda deliberadamente deshabilitado a la espera de la aprobación legal correspondiente.

No cambia el agente. Todas las capacidades de esta versión son del servidor y de la consola; la flota sigue con el agente v2.17.1 y no necesita actualizarse por este release.

Cambios en esta versión

• Certificados de borrado, verificables y a prueba de manipulación. El producto emite certificados —de destrucción remota o de destrucción física— y los guarda en un repositorio de sólo-escritura encadenado por hash: una vez emitido, un certificado no se modifica ni se elimina, y si alguien alterara o borrara un registro intermedio, la cadena se rompe y queda en evidencia. La evidencia sobrevive al borrado del propio equipo.
• Firma y verificación en la consola. Cada certificado se firma criptográficamente. Al abrir el detalle, la consola verifica por separado que el documento esté íntegro, que la firma sea válida y que la cadena no esté rota, y lo muestra con tres indicadores distintos: "sin firma" no es lo mismo que "firma inválida". La clave de firma vive fuera de la aplicación y el esquema queda preparado para firma electrónica avanzada.
• Reportería y descargas (PDF/JSON). Una vista dedicada lista los certificados con filtro por tipo y búsqueda, y permite descargar cada uno en PDF y en JSON con el mismo nombre que quedó registrado en la auditoría. En la ficha de cada equipo se suma una pestaña propia con sus certificados de borrado, disponible en cualquier plataforma —no sólo Windows—.
• Custodia de activos y destrucción física. Un formulario formaliza el ingreso del equipo a proceso de baja (cadena de custodia) y, desde ahí, se emite el certificado de destrucción física. Un activo no funcional o sin medio detectable se enruta directo a destrucción física, y la consola lo avisa para no prometer un borrado lógico que no va a ocurrir.
• Gobernanza del borrado: dos personas y ventana de arrepentimiento. Las órdenes de borrado exigen la segunda confirmación de una persona distinta de quien las ordenó y abren una ventana de arrepentimiento cancelable, con cuenta regresiva en pantalla. Hay una vista de gobernanza que lista las órdenes y ofrece, según su estado, confirmarlas o cancelarlas. Crear una orden destructiva es parte del bloque que sigue cerrado.
• Permisos separados. Se agregan tres permisos independientes —ordenar borrado (desactivado por omisión), ver certificados y gestionar ingresos de activos—, para que ver la evidencia no implique poder ordenar un borrado.

Lo que se verificó antes de publicar

Agente

Sin cambios. Esta versión no trae release de agente: las capacidades son del servidor y la consola, y el bloque destructivo del agente sigue cerrado. La flota permanece en v2.17.1 (ver sus notas en /release-notes/agent/).

Notas de actualización

• El despliegue es el de siempre: la API y el frontend por sus playbooks de Ansible. Esta versión agrega tablas nuevas (módulo erase) y un piso de retención en la configuración global; la migración corre con el despliegue de la API, sin pasos manuales.
• No hay que actualizar la flota por este release. El agente sigue en v2.17.1.
• El borrado destructivo remoto está deshabilitado a propósito y no se habilita en esta versión: la consola emite certificados y gobierna órdenes, pero no envía ninguna acción de borrado al equipo. Su apertura queda condicionada a la aprobación legal correspondiente y a un simulacro en seco previo.

---

Documentación: README.md. Uso interno de BrainCorp.

Esta versión estrena la cascada automática de contramedidas al marcar un equipo como perdido o robado. Hasta ahora, marcar un equipo abría el caso y encendía la geolocalización intensiva, pero bloquear la pantalla, sonar la alarma o evitar que el equipo se durmiera eran acciones que el operador disparaba a mano, una por una, desde otra pantalla. Ahora esas contramedidas se encadenan solas al marcar, según una configuración que se decide de antemano y en tres niveles.

Acompaña al agente v2.16.0, que ejecuta las contramedidas en el equipo (bloqueo diferido, override de cámara y no-hibernación en Windows). Contra un agente anterior, el marcaje sigue funcionando —el caso se abre y la evidencia se recolecta igual—, pero las contramedidas nuevas no se aplican hasta que el equipo actualice. En esta fase la cascada de bloqueo y no-hibernación es sólo Windows; macOS y Linux llegan en una fase posterior.

Cambios en esta versión

• La cascada se dispara al marcar. Marcar perdido/robado ya no es sólo "empezar a mirar dónde está": según la configuración, bloquea la pantalla, enciende la cámara, evita que el equipo se duerma y —si se pidió— suena la alarma. Todo con un solo acto del operador, y todo reversible al recuperar.
• Configuración en tres niveles con precedencia clara. Cada contramedida se decide en el nivel global (Configuración → valores por defecto), en el nivel por equipo (la ficha del equipo, para una flota o un usuario con reglas propias) y en el nivel por caso (el diálogo de marcar, para este robo concreto). La precedencia es caso > equipo > global: lo más específico manda, y cada control tiene tres estados —Heredar / Activar / Desactivar—, así que "Heredar" nunca es una caja negra: la ficha muestra qué valor se hereda hoy.
• Bloqueo silencioso y diferido. El bloqueo de pantalla no es inmediato: espera una ventana configurable mientras se recolecta evidencia (fotos, pantalla, ubicación), y recién entonces bloquea. Recuperar el equipo dentro de esa ventana cancela el bloqueo pendiente. Un 0 bloquea de inmediato; más alto recolecta más antes de cerrar la pantalla.
• Override de cámara por caso. Un equipo perdido puede forzar la captura de cámara aunque el interruptor global esté apagado, porque la proporcionalidad de sacarle una foto a quien tiene el equipo la sostiene el caso, no una preferencia global. El override vale sólo dentro del caso activo y sólo para ese caso; al recuperar, vuelve a mandar el interruptor global. Queda auditado con el motivo del marcaje.
• No-hibernación con revert limpio (Windows). Mientras el equipo está perdido, se evita que se suspenda o hiberne —si duerme, deja de reportar dónde está—. Al recuperar, el esquema de energía vuelve exactamente al que tenía antes: la contramedida no queda pegada. Un equipo que quede sin dormir para siempre sería un defecto silencioso, y esta versión existe justamente para no dejarlo.
• Revert total al recuperar. Cerrar el caso restaura el esquema de energía previo y cancela cualquier bloqueo pendiente. Ninguna contramedida sobrevive a la recuperación.
• Todo queda en la auditoría. Cada cascada disparada se registra con la configuración resuelta —qué se encendió sobre la persona que tiene el equipo— junto al motivo del caso y a quién lo marcó.

Lo que se verificó antes de publicar

Verificación del efecto en el equipo (bloqueo tras la ventana, powercfg sin hibernación con revert, cámara con el global apagado): se cierra por separado con el agente v2.16.0 desplegado en terreno.

Notas de actualización

• El despliegue es el de siempre: la API y el frontend por sus playbooks. No hay migración de datos nueva en esta versión (el modelo de configuración por equipo ya venía de la línea anterior).
• La flota Windows recibe el agente por la vía de actualización habitual; hasta que un equipo actualice, marcarlo abre el caso y recolecta evidencia, pero no aplica las contramedidas nuevas.
• El cifrado en robo sigue diferido: la cascada no cifra el disco (requiere activación remota y escrow de claves, que aún no existen). Sólo verifica el estado que ya reporta el monitoreo de cifrado.
• La cascada de bloqueo y no-hibernación es sólo Windows en esta versión; macOS y Linux llegan después.

Esta versión estrena el monitoreo de cifrado de disco (BitLocker) para la flota Windows: un panel de cumplimiento que dice, equipo por equipo, si el disco del sistema está cifrado, y un detalle por volumen dentro de la ficha de cada equipo. Es la primera versión del producto que expone en la consola todo el trabajo de cifrado que el agente ya venía midiendo y el servidor ya venía guardando.

Acompaña al agente v2.15.33, que lee el estado real de BitLocker y lo reporta en su check-in. Contra un agente anterior, un equipo aparece como "sin dato" hasta que actualice; el resto del producto se comporta igual que en la v1.4.12.

Cambios en esta versión

• Panel de cifrado de disco de la flota (Windows). Vista dedicada, hermana del panel de equipos perdidos, con una fila por equipo y el veredicto de su volumen de sistema. Filtros por estado, por cliente y por sitio. El estado se pinta con color: verde cifrado, rojo sin cifrar, gris no compatible, naranjo sin dato.
• Cuatro estados que no se fusionan. "Sin dato" —el equipo nunca reportó, la lectura falló, o no trae volumen de sistema— nunca se muestra como "sin cifrar". Mezclarlos marcaría como incumplidor a un equipo del que no se sabe nada todavía, que es justo el error que este panel existe para evitar. El equipo que nunca contestó aparece igual en la lista: es el que más importa ver.
• Detalle por equipo, en la pestaña de activos. Cada equipo Windows suma el estado de cifrado por volumen —método (p. ej. XTS-AES-128), porcentaje, protección y cantidad/tipo de protectores—, la fecha de la última medición y el registro de cambios (desde cuándo el estado es el que es).
• Botón para volver a medir. Pide al agente una lectura nueva reutilizando el mismo sysinfo que puebla el resto de los activos. Si el equipo está fuera de línea, la consola lo avisa y no envía el comando. El dato no cambia al instante: se actualiza cuando el agente vuelve a reportar (la latencia normal del check-in de inventario es de ~1 hora).
• Sin material de clave. El producto transporta y muestra sólo el estado: cantidad y tipo de protectores. Nunca claves de recuperación ni secretos.
• La consola traduce los códigos crudos de Windows. El agente y el servidor guardan los números de WMI sin interpretarlos; es la consola la que los lee a texto legible, en español e inglés, y un código desconocido de una versión futura de Windows se muestra tal cual en vez de tragarse.

Lo que se verificó antes de publicar

Veredicto de cumplimiento de un equipo con volumen de sistema cifrado de verdad: la sonda del agente ya se validó contra un volumen BitLocker real; el veredicto de extremo a extremo del panel (RN del volumen de sistema) requiere un equipo con C: cifrado y se cierra por separado.

Notas de actualización

• El despliegue es el de siempre: la API y el frontend por sus playbooks; el backend de cifrado (tablas e endpoints) ya venía de la línea anterior.
• No hay migración de datos nueva en esta versión más allá de la que ya estaba aplicada.
• La flota Windows recibe el agente 2.15.33 por la vía de actualización habitual; hasta que un equipo actualice, aparece como "sin dato", que es correcto.
• Los protectores de clave pueden verse como dato ausente en equipos que aún no reportan esa parte; es esperado, no un error.

Esta versión cierra la captura de pantalla del modo perdido en Linux con Wayland —el hueco que quedaba del ciclo de captura multiplataforma— y repone el control remoto en los Linux virtualizados. El grueso del cambio de captura vive en el agente; el producto lo acompaña, ofrece la versión nueva a la flota y suma un motivo más a la cronología del caso.

Acompaña al agente v2.15.28, que trae la captura por el portal de Wayland en GNOME y KDE. Contra un agente anterior, el producto se comporta igual que en la v1.4.11.

Cambios en esta versión

• Captura de pantalla del modo perdido en Linux con Wayland (GNOME y KDE). En los escritorios modernos, Wayland no deja que una aplicación lea la pantalla como en X11: hay que pedírselo al portal del escritorio. El agente lo hacía mal —pedía por un canal y escuchaba por otro—, así que la captura se tomaba pero se reportaba como espera agotada. El agente 2.15.28 lo corrige; en KDE, además, la imagen ya no se va por un camino de X11 que devolvía negro y se leía como avería. La foto de cámara ya funcionaba; ahora la pantalla completa el par.
• «Tomar control» restablecido en la flota Linux virtualizada. El control remoto del escritorio (KVM del Mesh) fallaba en Linux sobre VMware: el servicio del agente Mesh arrancaba con una capacidad del kernel (CAP_SYS_MODULE) que no usa y que el hipervisor rechaza, y la detección de sesión gráfica se caía por eso. Se le retira esa capacidad con un drop-in de systemd en toda la flota Linux, sin tocar el binario del Mesh.
• Nuevo script de endurecimiento del servicio de control remoto en la biblioteca, aplicable a la flota Linux, con una verificación posterior que ya no lee el estado antes de tiempo.
• macOS: se muestra el motivo cuando la cámara no entrega foto, y la desinstalación sigue correctamente al ayudante de captura renombrado (T016). La línea de tiempo deja de mostrar un hueco silencioso.
• Nuevo motivo pantalla_bloqueada en la cronología del caso. Si el equipo tenía la sesión bloqueada en el momento de la captura, el caso lo registra como tal en vez de contarlo como fallo.
• Estado de cifrado de disco más fiel. Se corrigieron unos valores de respaldo del check-in que habían quedado rezagados respecto de la recalibración anterior, de modo que el estado que reporta un equipo sin dato fresco deja de estar inflado.
• Ansible: los valores de check-in dejan de pisarse entre el producto y el inventario, un arreglo de despliegue sin efecto visible en la consola.

Lo que se verificó antes de publicar

KDE sobre Wayland ya estaba medido; wlroots (sway, Hyprland) usa una vía que no cambió y no se midió en un equipo real.

Notas de actualización

• El despliegue es el de siempre. Esta versión estrena la capacidad de captura en Wayland del lado del agente; del lado del producto, sólo cambia la versión que se ofrece a la flota.
• No hay migración de datos que revisar aparte de las de rutina.
• La flota Linux recibe el agente 2.15.28 por la vía de actualización automática habitual, y el drop-in de systemd del control remoto se aplica con el playbook de despliegue.

Cierre de la etapa del modo perdido o robado: la que convierte el caso en un documento. Hasta la v1.4.10 un caso se veía en la consola; desde esta versión sale de ella en un PDF que se sostiene solo, y las acciones de respuesta quedan en la misma pantalla donde se opera.

Acompaña al agente v2.15.20, que trae la ronda de permisos de macOS y la captura de pantalla en Wayland. Contra un agente anterior, el producto se comporta igual que en la v1.4.10.

Cambios en esta versión

• Exportación del caso a PDF. Un botón en el caso genera un informe pensado para leerse fuera de la consola: portada con el equipo, el motivo, quién lo marcó, cuándo, y la política de retención vigente; después el recorrido y la cronología completa. Las imágenes van embebidas en el documento, no enlazadas: un enlace a la consola es una pantalla de inicio de sesión para quien recibe el informe.
• Los dos relojes, siempre. Cada evento imprime la hora del equipo y la del servidor. Si el equipo estuvo sin red, entre las dos hay horas de diferencia; imprimir una sola sería elegir por el lector en el punto exacto que alguien va a discutir.
• Un permiso en la puerta y otro adentro. Exportar exige can_manage_lost_mode: el recorrido y la cronología son lo que hace falta para presentar una denuncia, y dejarlos tras el permiso de ver rostros dejaría sin documento a quien opera el caso. El permiso de ver la evidencia (can_view_lost_evidence) decide algo distinto: si el PDF lleva las imágenes. Un PDF se genera una vez y después circula solo, así que embeberlas para quien no puede verlas en pantalla sería la forma más limpia de saltarse esa separación.
• Cuando el informe sale sin imágenes, lo dice en la portada. Omitirlo en silencio convertiría un informe incompleto en uno engañoso.
• Cada exportación queda auditada, con quién la pidió y sobre qué caso, antes de generarse.
• Las acciones de respuesta, en la pantalla de equipos perdidos. Cada fila suma un menú con bloquear, mensaje en pantalla, alarma, detener alarma y exportar el caso. Son las mismas acciones y los mismos diálogos del listado general —no una copia—: lo que cambia es que dejan de estar a dos pantallas de distancia de quien está atendiendo el caso.
• El instalador de macOS avisa de los permisos que vienen. Le indica a quien instala que no cierre la sesión todavía y que hay dos solicitudes del sistema que debe aceptar. El instalador no puede dispararlas él —macOS le atribuiría el permiso a la Terminal desde la que se instaló, y el agente se quedaría sin él—, así que las pide el servicio a los pocos segundos de arrancar.
• Nueva página pública de uso aceptable y privacidad en docs.observer.cl, con las reglas de uso del modo perdido, qué evidencia genera, quién puede verla y por cuánto tiempo se conserva.

Lo que se verificó antes de publicar

Del lado del agente, la ronda de permisos de macOS y la captura en Wayland todavía no se han medido en un equipo real — el detalle está en las notas del agente v2.15.20. Ninguna de las dos toca el camino que hoy funciona en Windows, en Linux con X11 ni en macOS.

Notas de actualización

• El despliegue es el de siempre y no cambia ninguna configuración existente.
• No hay migración de datos que revisar aparte de las de rutina.
• La documentación pública se publica aparte: commitearla no la publica.

Cuarta etapa del modo perdido o robado: la que le pone cara al caso. Hasta la v1.4.9 un equipo marcado reportaba dónde estaba y qué había en su pantalla; desde esta versión, además, puede sacar una foto de la cámara de quién lo tiene delante.

Acompaña al agente v2.15.17, que es el que toma la foto. La actualización de la flota al nuevo agente se hace por la vía de siempre; contra un agente anterior, el caso sigue con ubicación y pantalla como hasta ahora.

Cambios en esta versión

• El modo perdido saca una foto de la cámara del equipo. Junto a la captura de pantalla, cada ciclo de un caso puede sumar una foto de quién está frente al equipo, y la línea de tiempo la muestra como una segunda miniatura. A diferencia de la pantalla, la foto no depende de que alguien haya iniciado sesión: sirve incluso en la pantalla de inicio, que suele ser justo donde está un equipo recién sustraído.
• Nace apagada de fábrica. Fotografiar la cara de una persona es cualitativamente más sensible que ubicar un activo, así que actualizar el producto no la enciende. Hay un interruptor global en Configuración que hay que activar a propósito; con él apagado, ningún equipo de la flota toma fotos.
• El LED de la cámara se enciende, y no se oculta. En la enorme mayoría de los equipos el LED está cableado a la alimentación del sensor y ninguna aplicación puede apagarlo. La foto nunca es invisible: el producto lo documenta en vez de prometer lo contrario, porque ocultarlo sería el peor camino y, además, algo que el hardware no permite cumplir.
• Una foto en negro nunca se sube como si fuera evidencia. La tapa de privacidad puesta o el cuarto a oscuras dan una imagen negra; el agente la mira antes de mandarla y, si no muestra nada, manda el motivo en su lugar. Un caso lleno de fotos negras parece tener evidencia y no la tiene.
• Disponible en Windows y Linux. En Windows la foto se toma sin ninguna herramienta extra. En Linux usa fswebcam o ffmpeg si están instalados, y si no lo están, el caso lo dice con todas sus letras. En macOS la función queda a la espera del permiso del sistema, que no se puede conceder a distancia.
• La foto hereda el cifrado y el plazo de borrado del caso, sin nada que configurar aparte: se guarda cifrada en el servidor y se borra sola con los mismos plazos que la captura de pantalla que llegó en la v1.4.9.
• Corregido: el interruptor de la foto de cámara surte efecto al instante, también al apagarlo. Antes, apagarlo durante un caso abierto no detenía las fotos hasta el siguiente reinicio del agente — al revés de como debe comportarse una perilla que existe justamente para poder dejar de fotografiar a alguien.

Lo que se midió en un equipo real

Terreno del 13 de agosto de 2026:

⚠️ macOS sigue sin foto de cámara en esta versión: el permiso de cámara no se puede conceder por administración remota, así que la función queda a la espera de que se autorice en el equipo.

Compatibilidad

• La foto de cámara requiere el agente v2.15.17. Con un agente anterior, el caso sigue reuniendo ubicación y captura de pantalla como en la v1.4.9.
• Sin cambios para las funciones existentes. La evidencia capturada antes de esta versión se sigue leyendo igual.

Tercera etapa del modo perdido o robado: la que le pone fecha de vencimiento a la evidencia. Hasta la v1.4.8 un caso acumulaba capturas y puntos de ubicación sin plazo y sin cifrar; desde esta versión se borran solos y se guardan cifrados en el servidor.

No cambia la versión del agente. Todo ocurre en el servidor; la flota sigue en la v2.15.16.

Cambios en esta versión

• La evidencia de un caso se borra sola a los 90 días, o unos días después de cerrarlo — lo que ocurra primero. Se va el archivo del disco, no sólo el registro.
• Dos plazos configurables en Configuración global. El de los 90 días no se puede desactivar.
• La evidencia se guarda cifrada en el servidor, con una llave propia de cada instalación.
• La línea de tiempo del caso declara ambas cosas: cuánto le queda a esa evidencia y si está cifrada.
• Corregido: los archivos de un equipo eliminado de la consola quedaban en el disco para siempre.

La evidencia se borra sola

Las capturas y los puntos de un caso se eliminan a los 90 días, y también unos días después de marcar el equipo como recuperado — lo que ocurra primero. Lo corre el propio servidor, cada hora, junto al resto del mantenimiento.

Lo que importa de esta función no se ve desde la consola: se borra el archivo del disco, no sólo el registro. Una consola que ya no lista la evidencia con las imágenes todavía en el servidor sería una retención cumplida en la pantalla e incumplida en los hechos, y nadie lo notaría hasta una auditoría.

Dos plazos, en Configuración global

El primero no admite el valor 0 a propósito. Las demás retenciones del producto (historial de chequeos, registros de auditoría) sí se pueden apagar: son de monitoreo y apagarlas sólo cuesta disco. Ésta no — apagarla dejaría capturas de pantalla de personas acumulándose sin fecha de término.

El segundo existe porque la denuncia suele presentarse después de recuperar el equipo. Borrar la evidencia dentro de la hora siguiente al cierre del caso es irreversible y llega tarde para quien la necesita. Quien prefiera el borrado inmediato al cerrar, pone 0.

La evidencia se guarda cifrada

Cada instalación genera su propia llave al instalarse. Quien lea el disco del servidor no ve las imágenes: encuentra material cifrado.

Desde la consola no cambia nada — la miniatura y la descarga funcionan igual que antes. Y lo capturado antes de esta versión se sigue leyendo: el cifrado se reconoce archivo por archivo, así que actualizar no deja ilegible ningún caso abierto.

La política, a la vista en el caso

La línea de tiempo muestra en cuántos días se borrará esa evidencia y si está cifrada. Un servidor que no la esté cifrando lo declara ahí mismo, en vez de que se descubra el día que alguien mire el disco.

Corregido: la evidencia que sobrevivía al equipo

Los archivos de un equipo eliminado de la consola quedaban en el disco del servidor para siempre: nadie los listaba, nadie los contaba y nadie los borraba. Ahora se recogen con el mismo plazo que el resto.

Lo que se verificó en un equipo real

Terreno contra el ambiente de pruebas, con un equipo Linux de escritorio:

Antes de actualizar

• Esta versión trae una migración (core.0062): dos campos nuevos con valor por omisión. No reescribe ninguna fila existente.
• Actualice con el playbook de instalación, no con el de despliegue de backend. La llave de cifrado se genera y se instala como parte de la configuración del servidor, y el despliegue de backend no la toca: quedaría un servidor al día pero guardando la evidencia sin cifrar. Lo declara en el caso, pero sin cifrar.
• ⚠️ Respalde la llave junto con el resto de las credenciales del ambiente. Si se pierde, la evidencia cifrada con ella no se recupera — no hay rescate posible, y es deliberado.
• La evidencia capturada antes de actualizar queda sin cifrar y se sigue leyendo con normalidad. Se irá con su plazo, como el resto.

Segunda etapa del modo perdido o robado de Observer RMM: la que le da ojos al caso. Hasta la v1.4.7 un equipo marcado decía dónde estaba; desde esta versión, además muestra qué se está haciendo con él.

Acompaña al agente v2.15.16, que es el que captura.

Cambios en esta versión

La línea de tiempo del caso

El detalle de un equipo marcado pasa a ser una línea de tiempo: un renglón por ciclo de captura, con la hora del propio equipo, dónde estaba —con su margen de error— y una miniatura de lo que había en su pantalla en ese momento. Al lado, el mapa dibuja el recorrido completo del caso.

La captura es silenciosa: no suena, no muestra ningún aviso y no deja ventanas a la vista. Y sale de la sesión de la persona que tiene el equipo, no del servicio del sistema; es la única forma de que la imagen no salga negra.

Ninguna imagen en negro entra al caso

El equipo mira la imagen antes de mandarla. Si está vacía, no la sube: manda el motivo en su lugar. Es la diferencia entre un caso con evidencia y un caso que parece tener evidencia — una carpeta llena de imágenes negras que nadie marcó como fallidas es peor que una carpeta vacía.

Cuando no se puede capturar, el ciclo igual queda registrado y el caso lo explica con todas sus letras:

• la pantalla del equipo estaba apagada;
• nadie había iniciado sesión todavía;
• el sistema no concede el permiso de grabación de pantalla (macOS);
• el equipo no tiene ninguna herramienta de captura instalada (Linux);
• la sesión no admite captura silenciosa (Linux con Wayland).

Ver la pantalla se concede aparte

Coordinar la recuperación de un equipo y mirar lo que su pantalla estaba mostrando son capacidades distintas, y se otorgan por separado. Quien sigue el recorrido de un caso no ve las imágenes salvo que se le conceda el permiso dedicado.

La evidencia se descarga desde la consola, con la sesión del operador y el permiso comprobado en cada descarga. No existe un enlace de archivo que funcione fuera de ella.

La evidencia no se acumula en el equipo perdido

La imagen se borra del equipo apenas se sube. Y si el equipo está sin red, el ciclo se pierde en vez de guardarse para después: dejar un depósito de capturas de pantalla —sin cifrar— en el equipo que alguien se llevó sería peor que perder una imagen.

Lo que se verificó en un equipo real

Terreno contra el ambiente de pruebas, con un equipo Linux de escritorio:

⚠️ Windows y macOS no tienen verificación de terreno de esta función al momento de publicar. En macOS hay además una limitación conocida y ajena al producto: el permiso de grabación de pantalla no se puede conceder por administración remota; si nadie lo autorizó a mano en el equipo, el caso recibirá el motivo correspondiente en vez de imágenes.

Antes de actualizar

• Esta versión trae una migración (agents.0065). Es un campo nuevo y anulable: no reescribe ninguna fila existente.
• El servidor necesita el directorio de evidencia (/opt/observer/lostmode/evidence). Los playbooks de instalación y de despliegue del backend lo crean solos; si despliega a mano, créelo antes con el usuario del servicio y permisos 0750.
• Los equipos se actualizarán solos al agente 2.15.16 al hacer check-in. Para escalonarlo, fije LATEST_AGENT_VER en la configuración local del servidor antes de desplegar.
• ⚠️ Pendiente, y conviene tenerlo presente al abrir casos: la evidencia todavía no se borra sola a los 90 días ni se guarda cifrada en reposo. Las dos cosas llegan en la etapa siguiente; hasta entonces, cerrar un caso viejo implica pedir el borrado de su evidencia.

Versión de mantenimiento de la plataforma Observer RMM. Cierra los tres hallazgos que dejó abiertos la verificación en terreno de la v1.4.6: dos de ellos afectaban la calidad de la evidencia del modo perdido y el tercero la hacía difícil de leer.

Acompaña al agente v2.15.15, que trae el tercero de esos arreglos.

Cambios en esta versión

🔴 Corregido: en modo perdido, la posición del sitio se guardaba como si fuera la del equipo

Cuando un equipo no logra medir su ubicación —una VM sin radio WiFi, por ejemplo— el producto le hereda las coordenadas declaradas de su sitio. Para un equipo estacionario esa herencia es correcta y es estrictamente mejor que un fix por IP, cuyo error se mide en centenas de kilómetros.

Para un equipo marcado como perdido es lo contrario: el recorrido del caso mostraba el equipo sentado en la oficina mientras alguien se lo llevaba. No es un dato pobre, es un dato falso, y un caso que puede terminar en una denuncia no puede llevar evidencia fabricada.

Con el equipo marcado, ahora se guarda la posición realmente medida —con su margen de error declarado, aunque sea de 20 km— o no se guarda ninguna. Fuera del modo perdido, la herencia del sitio sigue funcionando igual que antes.

Se detectó en terreno: los tres puntos que registró la verificación de la v1.4.6 decían sitio (declarada). Y se verificó el arreglo del mismo modo — el equipo marcado pasó de registrar sitio (declarada) con 1 km de incertidumbre a registrar ip con 20 km, que es la verdad de lo que ese equipo puede medir; fuera del modo perdido siguió heredando el sitio, como corresponde.

Corregido: el aviso de gobernanza no se podía leer en modo oscuro

El aviso que encabeza el módulo Equipos perdidos —el que recuerda que marcar exige un motivo, queda auditado y pasa por encima del interruptor global de ubicación— se pintaba con un fondo claro y dejaba que el texto heredara el color del tema. Con la interfaz en modo oscuro, eso era texto claro sobre fondo claro.

De paso, su texto citaba una referencia interna del proyecto. La consola no es el lugar de esa referencia: el aviso ahora dice lo mismo en el idioma del producto.

Agente

• La versión ofrecida a la flota pasa a la 2.15.15. Su cambio central: al marcar un equipo encendido y en línea, la ubicación intensiva empezaba en el siguiente ciclo normal —hasta media hora después—. Ahora arranca en el momento, y toma el primer punto de inmediato.

Antes de actualizar

• Los equipos se actualizarán solos a la 2.15.15 al hacer check-in. Si necesita escalonarlo, fije LATEST_AGENT_VER en la configuración local del servidor antes de desplegar.
• Esta versión no trae migraciones.
• Los puntos ya guardados como sitio (declarada) en casos anteriores no se reescriben: el producto no reinterpreta evidencia histórica. Lo que cambia es lo que se registra de aquí en adelante.

Versión de la plataforma Observer RMM de BrainCorp. Acumula lo trabajado desde la v1.4.5, y su cambio central es la primera etapa del modo perdido/robado: un equipo que sale del control de su dueño deja de ser un punto que se apagó y pasa a ser un caso, con motivo, autor, auditoría y una huella de ubicación que se puede reconstruir.

Esta etapa no captura pantalla ni fotos — eso llega en la siguiente. Lo que entrega es el andamiaje completo debajo: el estado, el permiso, la auditoría, la ubicación intensiva y el módulo en la consola.

⚠️ Esta versión sube la versión de agente ofrecida a la flota a la 2.15.14. Los equipos se actualizan solos al hacer check-in.

Cambios en esta versión

Modo perdido/robado — primera etapa

• Un equipo se marca como perdido desde la consola con un motivo obligatorio. No es burocracia: es lo que sostiene la proporcionalidad de encender una recolección de datos sobre la persona que tiene el equipo, y queda escrito en la auditoría. El único interruptor de apagado es marcarlo como recuperado.
• Mientras está marcado, el equipo reporta su ubicación entre una vez por minuto y una vez por hora (5 minutos por omisión, configurable al marcar). En operación normal el producto mantiene un piso de seguridad de 5 minutos entre capturas; el modo perdido lo saltea a propósito, porque un equipo que se mueve no se reconstruye con un punto cada media hora.
• Funciona con el equipo apagado. Si lo marcan mientras está sin energía o sin red, el equipo se entera al reconectarse: el aviso inmediato no es el único camino, el estado también viaja en la consulta de configuración que el agente hace por su cuenta. Marcar un equipo apagado no es un error y la consola lo trata como el caso normal que es.
• Sobrevive al reinicio. El estado se guarda en el equipo y se retoma al arrancar el servicio, sin esperar a hablar con el servidor. Un equipo robado se reinicia —lo apaga quien lo tiene, o se queda sin batería—, así que un estado que sólo viviera en memoria se perdería justo en el escenario para el que existe.
• Al marcarlo como recuperado, el rastro del marcaje se borra del equipo: no queda en el disco un archivo que delate que se lo estuvo siguiendo.
• Módulo "Equipos perdidos" en la consola: lista de equipos marcados, desde cuándo, quién y con qué motivo, y las acciones de marcar y recuperar. Es una sección propia con URL compartible, no un cuadro de diálogo — un caso se sigue en el tiempo.
• Dos permisos separados a propósito: Operar modo perdido y Ver evidencia. Coordinar la recuperación de un equipo no exige poder ver lo que la pantalla o la cámara capturen cuando esa etapa esté disponible.
• Sin fusible por falta de contacto, y es una decisión. Un equipo marcado que nunca vuelve a hablar con el servidor sigue en modo perdido indefinidamente. El caso de uso es precisamente un equipo que no vuelve.

🔴 Corregido: con la geolocalización global apagada, la ubicación del equipo perdido se descartaba

Una instalación nueva viene con la geolocalización apagada. Marcar un equipo como perdido pasa por encima de ese interruptor —así está declarado en la auditoría del marcaje— y el agente efectivamente empezaba a reportar cada minuto. El servidor descartaba cada uno de esos puntos.

El resultado era el peor de los dos mundos: el equipo gastaba batería y se exponía frente a quien lo tenía, y el recorrido quedaba vacío. Es decir, la función era un no-op de punta a punta exactamente en la configuración por omisión, que es donde más falta hace.

Se detectó midiendo contra un equipo real, no en las pruebas: las pruebas del servidor y del agente estaban todas verdes.

🔴 Corregido: el historial de ubicaciones se filtraba con la geolocalización apagada

La posición actual de un equipo se ocultaba cuando el interruptor global estaba apagado, pero el recorrido histórico completo seguía saliendo por otra vista. Era una fuga, no una decisión de diseño. Las dos vistas comparten ahora la misma regla.

Corregido: dos demoras que dejaban ventanas ciegas

• Al encender un equipo marcado, el modo perdido podía tardar hasta media hora en activarse, pese a que el dato ya venía en la primera consulta de configuración del arranque.
• Tras reiniciar un equipo ya marcado, la ubicación volvía a reportarse a la frecuencia normal por otra media hora, en vez de retomar de inmediato la del caso — justo lo que la persistencia del estado venía a evitar.

Las dos se midieron en terreno y las dos están cerradas: el estado se aplica en el arranque y la frecuencia del caso rige desde el primer segundo.

Biblioteca de scripts

• Cuatro plantillas nuevas para Linux y macOS.

Interno

• El job de la integración continua que valida el servicio de mensajería del servidor corría build y vet pero nunca ejecutaba las pruebas del paquete. Ahora las ejecuta: un test que no corre es un cero silencioso.

Antes de actualizar

• La versión de agente ofrecida sube a 2.15.14 y los equipos se actualizarán solos. Si necesita escalonarlo, fije LATEST_AGENT_VER en la configuración local del servidor antes de desplegar.
• Las migraciones de esta versión (agents.0064, accounts.0043, logs.0028) sólo agregan tablas y columnas; no reescriben datos existentes.
• Los permisos del modo perdido nacen apagados para todos los roles: hay que concederlos de forma explícita en cada rol que deba operarlo.

Versión de la plataforma Observer RMM de BrainCorp. Acumula todo lo trabajado desde la v1.4.4, y su cambio central es el modo mantenimiento: era un interruptor de silencio que suprimía alertas sin fecha, sin autor y sin decirlo en ninguna parte. Ahora se anuncia, se audita y avisa cuando se estira.

⚠️ Lea "Antes de actualizar" antes de desplegar. Esta versión cambia lo que el tablero pinta: sitios que hoy se ven verdes pasarán a mostrar su estado real.

Cambios en esta versión

Modo mantenimiento — visible, atribuible y con fecha de vencimiento humana

• Aviso permanente en el encabezado cuando hay equipos en mantenimiento: cuántos son, desde hace cuántos días está el más antiguo, y un botón que deja la lista filtrada por esos equipos. No se puede cerrar mientras haya equipos marcados: un aviso que se descarta vuelve a ser un olvido.
• El aviso respeta los permisos: un usuario que no ve un cliente tampoco ve sus equipos en el conteo.
• Cada equipo marcado muestra desde cuándo y quién lo activó, en el tooltip de la lista y en la ficha del equipo.
• Auditoría del cambio masivo. Activar o desactivar el modo mantenimiento por cliente o por sitio deja una entrada con el usuario, el alcance y los equipos afectados. Antes usaba una escritura directa a la base que no dejaba ningún rastro: nadie podía saber quién había silenciado un sitio entero.
• Aviso por correo cuando un equipo supera el umbral de días en mantenimiento. Configurable en Configuración global (3 días por omisión, se puede apagar). Un solo aviso por equipo y por ventana; bajar y volver a subir el modo mantenimiento empieza una ventana nueva.
• No se agregó caducidad automática, y es a propósito. Hay ventanas de mantenimiento que legítimamente duran días; apagarlas solas sería peor que el olvido. Lo que cambia es que el olvido ahora se ve.
• Los equipos que ya estaban en mantenimiento antes de actualizar aparecen con fecha "desconocido". La migración no inventa una fecha que no tiene; esos equipos igual cuentan en el aviso y igual disparan el correo.
• El color no cambia. El ícono de la fila y los nodos del árbol siguen en verde para los equipos en mantenimiento. El aviso lo carga el encabezado, no el color de las filas.

🔴 Corregido: un equipo en mantenimiento ocultaba a todo su sitio

Al calcular el estado de un sitio y de un cliente, el primer equipo en mantenimiento interrumpía la evaluación completa: los demás equipos del sitio no se miraban, y el sitio y el cliente se pintaban sanos aunque hubiera equipos fallando.

El impacto es proporcional a cuántos equipos estén marcados. En el ambiente donde se detectó, con 8 de 10 equipos en mantenimiento, explicaba buena parte de por qué la consola se veía tranquila durante cuatro días.

Al actualizar, sitios que hoy se ven verdes van a aparecer en rojo. Eso es el arreglo, no una regresión: esos equipos ya estaban fallando y estaban tapados. El equipo en mantenimiento se sigue ignorando y sigue verde — lo que deja de hacer es tapar a sus vecinos.

Seguridad de la configuración global

• La contraseña SMTP, los tokens de Twilio y de MeshCentral y la clave del asistente de IA ya no se pueden leer desde la consola: una vez guardados sólo se reemplazan o se borran. La consola indica si hay algo configurado, sin conocer el valor, y tampoco quedan en el registro de auditoría. Dejar el campo vacío significa "no lo toqué"; para quitar un secreto hay que borrarlo de forma explícita.
• Los datos de conexión con MeshCentral pasan a sólo lectura en la consola. Editarlos ahí nunca fue la vía correcta: el valor que manda lo despliega Ansible, la edición no persistía, y hasta el siguiente despliegue completo podía dejar "Tomar control" roto. Lo único que queda editable de esa pestaña es el nombre visible de la compañía.

Agentes e instaladores

• La consola marca los equipos con el agente de 32 bits instalado sobre un Windows de 64 bits. Ese equipo se ve perfectamente sano —está en línea, reporta, su registro dice que se está actualizando— pero la actualización nunca surte efecto: vuelve a descargar el mismo paquete cada hora, para siempre, y su inventario de software queda incompleto. Hasta ahora no había forma de distinguirlo en la consola.
• Los instaladores de Linux y macOS verifican la arquitectura del equipo y se niegan a instalar el agente equivocado. El modo de falla que esto ataja no es ruidoso: el binario de 32 bits corre sin error sobre un equipo de 64 bits, y el equipo queda pidiendo esa arquitectura indefinidamente.
• Corregido: el instalador de Windows installer.ps1 no corría en Windows 7 de fábrica (PowerShell 2.0), que es justamente la única plataforma para la que existe el agente de 32 bits. Terminaba en un "Unable to connect to server" y cero instalación.

Operación

• Censo diario de nodos huérfanos de MeshCentral: registros que quedaron de un enrolamiento fallido y que, por definición, no aparecen en ninguna pantalla de la consola. El censo sólo informa, no borra; el borrado sigue siendo un procedimiento manual.
• Dos plantillas de scripts nuevas para censar y limpiar los archivos que quedan en Windows tras migrar un agente de 32 bits a 64. Ese residuo no es inerte: borrarlo sin cuidado deja tareas programadas rotas en silencio, y por eso el censo y la limpieza van separados y no se automatizan.
• Corregido: los correos de alerta se reportaban como enviados aunque el servidor SMTP los rechazara — conexión rechazada, login fallido, tiempo agotado. El botón "Probar" de la consola era la única ruta inmune al problema, así que el transporte podía verificarse verde mientras las alertas reales no salían.
• Corregido: cuando la hora de una desinstalación manual llegaba ilegible, el producto lo dejaba pasar en silencio. Ahora queda registrado.

Consola

• Corregido: al escribir un secreto en la configuración, el tabulador duplicaba el primer carácter.
• Corregido: tres textos quedaban en inglés con la interfaz en español.
• Corregido: el borrador de script generado con IA llegaba con el razonamiento interno del modelo mezclado en el código.
• Corregido: la plantilla de servicios reportaba FALLA a servicios que sí habían arrancado.

Antes de actualizar

⚠️ El tablero va a cambiar de aspecto. Por el arreglo descrito arriba, los sitios y clientes que hoy se ven sanos por tener un equipo en mantenimiento pasarán a mostrar el estado real de los demás equipos. Conviene avisarlo al equipo de operación antes del despliegue, para que no se lea como una falla del despliegue.

⚠️ Revise el modo mantenimiento antes de actualizar. Con esta versión el aviso aparecerá apenas alguien entre a la consola. Si hay equipos marcados desde hace tiempo, su fecha figurará como "desconocido" (el producto no la inventa) y entrarán en el primer correo de aviso, que es el comportamiento buscado: un mantenimiento sin fecha es uno que nadie está mirando.

Migraciones

Esta versión sí trae migraciones de base de datos: agents/0063 (metadatos del modo mantenimiento) y core/0061 (umbral y activación del aviso por correo). El propio despliegue las aplica. Ninguna borra ni reescribe datos existentes: los campos nuevos nacen vacíos.

Agente

LATEST_AGENT_VER no cambia en esta versión: sigue siendo la 2.15.1. La promoción de la 2.15.3 a producción es una decisión aparte.

Actualización

Despliegue con Ansible sobre la instalación existente (deploy-api.yml y deploy-frontend.yml).

El frontend debe redesplegarse: esta versión trae cambios de consola (el aviso del encabezado, el filtro y los tooltips) y sube APP_VER, que es lo que le pide al navegador recargar la aplicación.

---

Instalación y guía: ver README.md.

Licencia: uso interno BrainCorp.

Versión de mantenimiento de la plataforma Observer RMM de BrainCorp. Un solo cambio: el producto pasa a ofrecerle a la flota el agente v2.15.1.

Cambios en esta versión

Agente ofrecido a la flota

• LATEST_AGENT_VER pasa de 2.14.3 a 2.15.1. Es la versión que la consola ofrece y a la que los equipos se actualizan solos al hacer check-in.
• La 2.15.1 corrige los acentos y la ñ en los scripts ejecutados sobre Windows en español: antes se perdían tanto en el código del script como en su salida. Verificado en dos equipos Windows en español reales.
• El valor por omisión del producto estaba una versión atrás desde que se publicó la 2.15.1. Los ambientes que ya la ofrecían lo hacían mediante un pin de inventario (observer_latest_agent_ver), que sigue funcionando y manda sobre este valor cuando está declarado.

Agente

Esta versión se acompaña del Observer RMM Agent v2.15.1 (notas). No hay que reinstalar nada: la flota se actualiza sola.

Actualización

Despliegue con Ansible sobre la instalación existente (deploy-api.yml y deploy-frontend.yml).

⚠️ LATEST_AGENT_VER se sirve desde local_settings.py, que deploy-api.yml no re-renderiza (lo excluye del synchronize para no pisar secretos). En una instalación cuyo inventario declare observer_latest_agent_ver, ese pin es el que manda y hay que actualizarlo ahí; si el pin apunta a una versión anterior, seguirá ganándole a este valor por omisión.

Esta versión no trae migraciones de base de datos propias. Quien venga desde v1.4.2 o anterior sí recibirá las de v1.4.3, que el propio despliegue aplica.

---

Instalación y guía: ver README.md.

Licencia: uso interno BrainCorp.

Versión de funcionalidades de la plataforma Observer RMM de BrainCorp. Suma la biblioteca de plantillas de scripts propia del producto y el Asistente IA para redactar scripts, además de la respuesta ante la desinstalación manual del agente y las correcciones acumuladas desde v1.4.2.

Cambios en esta versión

Biblioteca de plantillas de scripts

• 44 plantillas propias del producto para Windows, Linux y macOS, que se cargan solas con el despliegue. Ya no se clona ningún repositorio externo: los scripts son parte del producto y se versionan con él.
• Se distinguen en el Administrador de scripts con isotipo propio, y el interruptor de la barra ahora dice qué hace de verdad: mostrar u ocultar las plantillas frente a los scripts que escribe el operador.
• Abrir una plantilla muestra sus argumentos y variables de entorno, que se pueden ajustar para una prueba puntual sin clonarla. La consola avisa que esos cambios no se guardan.
• Las plantillas están escritas para funcionar igual en un equipo en español que en uno en inglés: no comparan texto traducido del sistema operativo, sino identificadores estables.

Asistente IA

• Pestaña "Asistente IA" en Configuración global. Funciona con cualquier proveedor que exponga una API estilo OpenAI: se configuran la URL base, el modelo, el límite de tokens y la temperatura.
• La temperatura puede dejarse vacía, porque hay modelos que rechazan la petición completa si se les manda un valor distinto del suyo por omisión.
• Botón "Generar borrador con IA" en el Administrador de scripts: se describe en lenguaje natural lo que se necesita y la IA redacta el script en el editor, para revisarlo antes de guardarlo.
• El despliegue puede sembrar una credencial de cortesía sin pisar la credencial propia del cliente si ya hay una configurada.

Respuesta ante la desinstalación manual del agente

• Cuando alguien desinstala el agente a mano en el equipo, la consola ahora se entera: llega una alerta por correo con quién, dónde y cuándo, y queda registro en el log de auditoría.
• El equipo se da de baja de la consola y de MeshCentral tras una ventana de gracia de 10 minutos, cancelable. La ventana existe porque reinstalar el agente ejecuta esa misma desinstalación, y un reinstalador no debería perder el historial del equipo.
• La alerta sobrevive al borrado del equipo: se guarda sin depender del registro que la denuncia.

Otros

• La alarma antirrobo suena al volumen máximo del equipo y no se detiene bajando el volumen.
• Geolocalización y su forzado quedan activados por omisión en instalaciones nuevas.
• Documentación pública en docs.observer.cl, indexable, con la tabla de funciones soportadas por plataforma y la guía del borrador con IA.

Correcciones

• Corregido: el cuadro para pedirle el borrador a la IA era un campo de una sola línea. Uno escribía tres renglones y solo veía el último tramo, sin poder releer la instrucción antes de enviarla. Ahora es un cuadro amplio, con ejemplos clicables, contador de caracteres y Ctrl+Enter para generar.
• Corregido: la espera por la respuesta del proveedor de IA sube de 60 a 120 segundos. Con 60 se descartaban modelos que responden bien pero lento. Mientras espera, la consola muestra los segundos transcurridos en vez de una rueda sin información.
• Corregido: el desinstalador del agente en Linux se quedaba colgado esperando una confirmación en pantalla que nadie iba a dar.
• Corregido: la desinstalación en macOS quedaba colgada cuando MeshCentral no respondía.
• Corregido: el respaldo programado informaba éxito sin haber escrito el archivo.
• Corregido: la hora de las alertas se informaba en una zona horaria distinta de la del producto.
• Corregido: respuestas inválidas del servidor de control ya no se registran como identificadores de equipo.

Agente

Esta versión se acompaña del Observer RMM Agent v2.15.1 (notas), que corrige los acentos y la ñ en los scripts ejecutados sobre Windows en español: antes se perdían tanto en el código del script como en su salida. La flota se actualiza sola al hacer check-in; no hay que reinstalar nada.

La versión que cada ambiente ofrece a su flota se fija por inventario (observer_latest_agent_ver), así que un ambiente puede quedarse en una versión anterior del agente aunque corra esta versión del producto.

Actualización

Despliegue con Ansible sobre la instalación existente (deploy-api.yml y deploy-frontend.yml). Esta versión trae migraciones de base de datos, que el propio despliegue aplica.

APP_VER sube a 0.0.205: las consolas que estén abiertas mostrarán el aviso de recarga.

---

Instalación y guía: ver README.md.

Licencia: uso interno BrainCorp.

Versión de mantenimiento y funcionalidades de la plataforma Observer RMM de BrainCorp. Suma la geolocalización de activos y la respuesta rápida sobre el equipo (bloqueo remoto, mensaje en pantalla y alarma sonora), además de las correcciones acumuladas desde v1.4.1.

Cambios en esta versión

Respuesta rápida en el equipo

• Bloqueo remoto de pantalla, mensaje en pantalla y alarma sonora, disponibles equipo por equipo o como acción masiva desde la consola.
• El bloqueo es el nativo del sistema operativo (el equivalente a Win+L), no un candado propio.
• Las tres acciones tienen permiso propio por rol —se otorgan por separado, porque su impacto sobre el usuario del equipo es muy distinto— y quedan registradas en el log de auditoría, tanto si se ejecutan como si fallan.
• Cuando una acción no se puede completar, la consola explica por qué en el idioma del operador: nadie con sesión abierta, sin herramienta de diálogo, sin reproductor de audio, o sin método de bloqueo disponible.

Geolocalización de activos

• Mapa con la ubicación de cada equipo y trayectoria histórica de posiciones.
• Ubicación por redes WiFi cercanas, con precisión típica de unos 20 metros, en vez de solo por dirección IP. En macOS se usa la ubicación nativa del sistema operativo.
• Coordenadas declarables por sitio, que se usan como respaldo cuando el equipo no puede resolver su posición por sí mismo.
• Geocerca opcional por equipo, con alerta por correo y aviso en la consola cuando un activo sale del perímetro de su sitio.

Otros

• Control remoto compatible con doble proxy inverso.
• Notas de versión de las publicaciones anteriores del producto disponibles en el changelog público (agents.observer.cl/changelog/).

Agente

Esta versión se acompaña del Observer RMM Agent v2.14.2 (notas). La flota se actualiza sola al hacer check-in; no hay que reinstalar nada.

Actualización

Despliegue con Ansible sobre la instalación existente (deploy-api.yml y deploy-frontend.yml). Esta versión trae migraciones de base de datos, que el propio despliegue aplica.

---

Instalación y guía: ver README.md.

Licencia: uso interno BrainCorp.

Primera publicación versionada de la plataforma Observer RMM de BrainCorp: monitoreo y administración remota de flotas (RMM) desplegable con Ansible sobre Ubuntu, sin Docker. Esta versión consolida el producto (backend Django + capa Go/NATS + frontend Vue/Quasar), el agente multiplataforma y el despliegue con Ansible en un estado probado end-to-end y en producción (tier1).

Destacados

Plataforma

• Consola web completa (Vue/Quasar) con tema propio Observation Deck.
• Internacionalización ES/EN de toda la UI (128/128 vistas) y del módulo de Reportes; idioma por defecto es-CL.
• Reportería: 19 plantillas curadas (inventario de equipos, especificaciones, software, actualizaciones de Windows, auditoría, cobertura de antivirus) + 4 dashboards con gráficos self-hosted (sin CDN externo); exportación HTML/PDF, editor Jinja, consultas de datos y reportes programados por correo.
• Alertas por correo (SMTP) y control remoto integrado (MeshCentral).
• RBAC, 2FA, registro de auditoría, campos personalizados y políticas de automatización.

Agente

• Observer RMM Agent v2.10.8 — Windows, Linux y macOS (amd64/arm64/386/arm), distribuido por CDN propio (agents.observer.cl). Actualización de flota automática al hacer check-in.
• El instalador de Linux ya no aborta en estaciones con entorno gráfico: maneja DISPLAY automáticamente y se instala headless.

Despliegue

• 6 roles Ansible (PostgreSQL 15, Redis, MeshCentral, API Django + NATS + Celery, nginx + TLS) en modo all-in-one, greenfield, sin Docker.
• TLS por ACME (wildcard, desafío DNS-01) o certificados provistos; credenciales autogeneradas y cifradas.
• Publicación a Internet detrás de un reverse-proxy corporativo, con recuperación de la IP real del cliente y manejo del pin de certificado del canal de control remoto tras double-proxy.

Robustez y correcciones

• Mejoras de UX del frontend: autocompletado de login, ordenamiento de alertas y estado de equipos, popups centrados multi-monitor, mejor manejo de errores.
• Mejoras de backend: validación del token de firma de código, hostname en los asuntos de alerta, limpieza de instalación en macOS.

---

Instalación y guía: ver README.md.

Licencia: uso interno BrainCorp.