Migración de agentes FusionInventory Agent a GLPI Agent -

GLPI es una aplicación de código abierto, distribuida sobre la licencia GPLv3+, diseñada para la gestión de parque informático. Se compone de un conjunto de servicios web que permiten identificar y gestionar todos los activos de hardware y software de un sistema informático, así permite optimizar el trabajo de los técnicos gracias a un mantenimiento más coherente y colaborativo.

Por otra parte, GLPI Agent es un componente escrito en PERL (lenguaje interpretado de automatización presente en todas las plataformas) que permite la ejecución de algunas otras tareas para implementación de paquetes, la recopilación de información, el descubrimiento e inventario de dispositivos de red e inventario remoto tanto de máquinas como ESX, en pocas palabras un sucesor del proyecto FusionInventory Agent.

En este artículo quiero enseñarte cómo lograr migrar tus agentes de FusionInventory Agent a GLPI Agent haciendo uso de los módulos que estos poseen como utilidades hacia estos casos de uso.

Esto debido a las importantes mejoras que ha comenzado a introducir Teclib (editor oficial de la herramienta y sus componentes desde 2015):

Seguridad SSL y Autenticación básica
Modo Proxy Agent
Toolbox de administración HTTP server
Inventario de bases de datos (MySQL, MSSQL, PostgreSQL, MongoDB, Oracle, DB2)
Inventario de virtualizadores (WSL, Docker, HyperV, Parallels, LXC, VirtualBox, VMware, Cirtix Xen, HPVM, QEMU, entre otros)
Inventario de software dedicado a gestión remota (AnyDesk, MeshCentral, TeamViewer, RustDesk, SupRemo, LiteManager)
Inventario remoto por SSH y WinRM
Inventario mejorado para equipos iDRAC
Protocolo JSON e inventarios parciales
Soporte a equipos Mac OSX en ARM y x86_64

Tabla de contenidos

Requerimientos:

GLPI >= v10.0.2, se recomienda 10.0.5+
GLPI Inventory plugin >= 1.0.4 instalado
Servidores con FusionInventory Agent >= 2.3 instalado
Script o paquete de automatización

En primer lugar, aunque no hace parte de esta guía y es bastante sencillo, teniendo en cuenta que anteriormente gestionábamos nuestros agentes haciendo uso de fusioninventory-plugin (Fi4G9.5+3.0, por ejemplo) nuestros agentes se encuentran desplegados apuntando a una dirección web. Si teníamos personalizado el punto de acceso, podemos ignorar esta recomendación, pero para este caso, tenemos que direccionar todas las llamadas de /plugins/fusioninventory/ a /marketplace/glpiinventory/ esto para preservar la funcionalidad de nuestro modulo objetivo Package Deploy.

Una vez completado lo anterior, ya tenemos garantizada una parte significativa de la migración. Otro elemento que si debe tener bastante atención, el cual podría ocasionarnos alguna dificultad seria, será nuestro script o paquete de automatización. En este último debemos depositar el acceso privilegiado a los componentes de nuestro sistema en la arquitectura objetivo de servidores, resumiendo a privilegios, uso de proxies web para descarga de recursos y agente de GLPI, entre los elementos relacionados. Allí debemos tener en cuenta el gestor de paquetes de sistema operativo, posibles problemas de dependencias y planificación de ejecución.

NOTA: Recuerda que lo más recomendable para realizar la instalación de plugins, es hacer uso del Marketplace, esto para no afectar los privilegios en directorios de la aplicación y generar riesgos potenciales de seguridad.

¡Manos a la obra!

Para comenzar ahora sí, con nuestro proceso de migración, dirígete a tu GLPI e ingresa a GLPI Inventory Administration

Si estas en GLPI 10.0.5 asegúrate de tener habilitado el inventario

Ahora dirígete a Deploy > Package deployment o más específicamente /marketplace/glpiinventory/front/deploypackage.php, vamos a añadir nuestro procedimiento de despliegue de script de migración o paquete de automatización.

Desde la sección de Package actions de nuestro procedimiento de despliegue, vamos a cargar el archivo a depositar en nuestros servidores (el nuestro se llama migrate.sh)

Posteriormente vamos a preparar el entorno de ejecución, este debe garantizar la existencia y alcance de cada recurso utilizado en el script, esto con el fin de evitar bucles de ejecución en modo error:

Por ejemplo, nosotros tenemos 6 acciones que van relacionadas a los recursos de nuestro script o paquete de automatización y constan de lo siguiente:

Una vez descargado el script, desplazarlo a la carpeta /home
Darle privilegios de ejecución como archivo
Validar si existe un pool de tareas en el cron del usuario root o de lo contrario crearlo
Importar la tarea de ejecutar el script entregado a través de GLPI, que ahora se encuentra en el directorio /home
Por último, dejar un rastro de ejecución en el equipo con fines de auditoría y seguimiento de migración.

Una vez terminado el flujo de acciones, deberás configurar una franja horaria para permitirle a nuestros agentes, iniciar el lanzamiento de migración. Está puedes agregarla desde el menú Task > Time slot o /marketplace/glpiinventory/front/timeslot.php, es importante que tengas en cuenta allí si la franja es suficiente para que te permita reaccionar rápidamente a una indisponibilidad provocada, también con el fin de tener la capacidad de atención necesaria al número de equipos destinados a migrar:

Ya para terminar, será necesario crear la solicitud de migración a nuestros agentes de FusionInventory Agent a través de la tarea correspondiente, que monitorearemos en el transcurso de su terminación. Ahora debes dirigirte al menú Task > Task managment o /marketplace/glpiinventory/front/task.php, y añadir una nueva programación:

Muy importante tener desactivada la reimplementación de la tarea, ya que esto podría generar un bucle de migración en la cual perdamos la administración desde GLPI.

En el formulario posterior vamos a tener en cuenta lo siguiente:

Schedule start: Te permitirá indicar desde cuando se podrán destinar recursos de la aplicación o componentes para la realización de la tarea.
Schedule end: El último momento para poder seguir reproduciendo acciones de nuestro Package Deploy.
Preparation timeslot: Rango de tiempo destinado a que GLPI asigne las maquinas su correspondiente flujo de migración.
Execution time: Rango de tiempo para que el agente pueda dar inicio a las Package actions.
Active: Trigger para suspender cualquier procedimiento de la tarea de migración.

Posteriormente nos restará evaluar el avance de nuestra migración, allí podremos ver los casos exitosos, que son resultado de los Package actions indicados.

A medida que cada equipo registre su estado satisfactorio, como muestra el Package deploy en Job executions, nuestro script o paquete de automatización para este escenario, empezará a validar si ha cumplido el tiempo necesario para lograr activarse.

A partir de allí, cada servidor que active el script preparará el entorno de despliegue necesario (validación de dependencias, conectividad de red, privilegios de usuario y demás parámetros) con el fin de permitir que la ejecución sea exitosa de inicio a fin. Al finalizar, este se encargará de realizar la limpieza necesaria al cron afectado, para evitar problemas de ejecución múltiple a pesar de que está programado para impedirlo. Inmediatamente termine la ejecución de migrate.sh, veremos registrado en nuestro GLPI la nueva versión de agente y la anterior desaparecerá.

Conclusión

Nuestro script o paquete de automatización será vital para el correcto desempeño de nuestra migración, es necesario que manejes allí puntos de control de ejecución, diagnosticar una entrada y evaluar si las salidas de los recursos lanzados cumplen con la documentación descrita por cada uno de ellos. Es decir, antes de poder determinar la ejecución de un comando, se debe garantizar que todas las condiciones previas se han proporcionado de manera correcta y en caso contrario, tener un plan de aborto o restauración.

Es posible migrar tanto agentes de FusionInventory como la actualización masiva del GLPI Agent (manteniendo siempre actualizado tu agente en la última versión estable). Como lo hemos hecho en este trabajo que decidimos compartir con ustedes, logramos alcanzar más de 1300 equipos que se encontraban con la posibilidad de conectarse al GLPI y así poder gestionar las tareas como lo esperado.

Acerca de Imagunet

Imagunet es una empresa colombiana apasionada por el software open Source el cual nos permite brindar soluciones confiables, robustas, escalables y costo-eficientes construidas por los mejores socios de la industria.

Nos enfocamos en ofrecer soluciones integrales a nuestros clientes, dándoles la posibilidad de avanzar en sus ideas, proyectos, estrategias sin ningún tipo de limitante. De manera segura y con el respaldo de un equipo profesional adaptable, capacitado y certificado en cada una de las herramientas que implementamos.

¿Quieres realizar la migración de FusionInventory Agent a GLPI Agent ? Contáctanos para obtener apoyo por parte de nuestros expertos o escribenos a sales@imagunet.com

Miguel Angel Ruiz Torres

También te puede interesar: