Pandora RMM

El nombre de RMM tiene su origen en las siglas de Remote Monitoring and Management.

Se trata de un sistema centralizado que permite crear y programar tareas desde la Consola web de Pandora FMS y que serán ejecutadas de manera local por los agentes para posteriormente reportar al servidor la información relativa a las ejecuciones realizadas y su estado. Se implementa a partir de la versión 778 de Pandora FMS y se distribuyen junto al servidor y agente los componentes necesarios para su funcionamiento.

Cuenta con 3 componentes:

• Agente RMM:

Es el encargado de conectar con el servidor RMM en busca de nuevas ejecuciones, llevarlas a cabo en caso de haberlas y enviar dos tipos de ficheros: keepalive y data. Estos ficheros tienen un formato JSON y contienen información como puede ser el nombre del agente, la fecha de envío de dicho fichero, el intervalo que está siguiendo el agente, el estado que tendrá la ejecución, etcétera.

• Servidor RMM:

Aloja los scripts y las ejecuciones encoladas y programadas que llevarán a cabo los agentes RMM.

• Servicio Tentacle RMM:

Permite la conexión entre cliente y servidor RMM. En su configuración se indican parámetros para la contraseña y certificados utilizados para el cifrado de la conexión, el tipo de ficheros que leerá y la configuración de directorios para hacer que sean solamente para subida o solamente para bajada. Por defecto las carpetas de rmm, res y queue solamente son para descarga y las de data y keepalive solamente para subida.

Como se ha mencionado, RMM se implementa en la versión 778 de Pandora FMS y se incluyen los componentes necesarios para su funcionamiento con el servidor y el Agente software. La parte del Pandora FMS server incluye también la parte de Tentacle, por lo que con una instalación habitual en 778 o actualización a dicha versión es suficiente para cumplir con los requisitos de uso. Esto incluye los certificados para el cifrado de la conexión mediante Tentacle entre agente y servidor RMM, aunque se pueden usar certificados SSL propios y cambiar la contraseña de conexión.

En cuanto a la configuración, es un proceso en dos pasos:

• Habilitar el servidor de RMM del PFMS server

Para ello se debe modificar el fichero de configuración del servidor. Si se cuenta con configuración remota habilitada se debe hacer desde la Consola web, caso contrario desde el terminal. Se necesita de modificar la línea #rmmserver 1 y descomentarla.

También hay dos parámetros adicionales para RMM: rmmserver_threads y rmmdir. Permiten elegir la cantidad de hilos destinados a la ejecución del servidor de RMM e indicar el directorio local de la máquina que se utilizará para el intercambio de datos con los agentes RMM, respectivamente. Este directorio será donde el servicio de tentacle_rmm gestionará los ficheros que intercambie con los agentes

Al guardar los cambios se podrá esperar a su aplicación automática o bien reiniciar manualmente el PFMS server. Desde la vista de la consola web, en el listado de servidores, se podrá comprobar de manera visual si el RMM server se encuentra activo:

También se puede comprobar a nivel de terminal que el proceso de Tentacle para RMM se encuentre activo. Este proceso debería crearse automáticamente tras habilitar el RMM server.

• Habilitar el agente RMM

Para habilitar el agente RMM también se debe modificar el fichero de configuración de cada agente. Cabe destacar que funciona tanto para agentes GNU/Linux® como MS Windows®. Se debe modificar el valor de la línea rmm_enabled a 1. Otros parámetros:

rmm_interval: Determina cada cuánto tiempo comprueba el agente RMM si existen ejecuciones encoladas para sí mismo y ejecutarlas. Por defecto está establecido a 30 segundos. También indica cada cuánto tiempo enviará los ficheros .keepalive para informar de su estado de conexión.

rmm_server: Indica la dirección IP o nombre DNS del servidor RMM. Por defecto, esta línea está comentada y usa la misma dirección o nombre DNS que se indique en el parámetro de server_ip para el agente software. Aquí se puede indicar una dirección o nombre distinto si el RMM server se encuentra en una máquina diferente al PFMS server del agente software.

rmm_port: Indica el puerto que se usará para las conexiones Tentacle, y deberá ser el mismo que esté utilizando el PFMS server. Por defecto es 41123.

rmm_temp: Indica el directorio local para ficheros temporales relacionados con las ejecuciones de RMM. Por defecto indicará /tmp en agentes para GNU/Linux® y C:\Program Files\pandora_agent\temp en los agentes MS/Windows®.

rmm_extra_opts: Este parámetro indica las opciones adicionales de conexión con el servicio de tentacle_rmm, entre otros incluye la contraseña o clave necesaria para establecer la conexión mediante Tentacle para las ejecuciones RMM. Está configurado por defecto, en caso de necesidad se puede encontrar en el fichero /etc/tentacle/tentacle_rmm.conf del servidor, en el parámetro password.

rmm_debug: Indica el fichero local donde se almacenarán las entradas de logs o debug, en caso de que se habilite dicho modo. En agentes GNU/Linux® es /var/log/pandora/pandora_rmm.debug y en agentes MS/Windows® es C:\Program Files\pandora_agent\pandora_rmm.debug por defecto.

Una vez se hayan guardado los cambios, se puede esperar al siguiente intervalo del agente o bien reiniciarlo manualmente. Una vez tomen efecto los cambios se puede observar el proceso de pandora_rmm_agent en el dispositivo:

Como se ha mencionado, es el agente el que se conecta al servidor RMM en busca de ejecuciones a realizar y para reportar los estados convenientes. Todo esto se hace a través de Tentacle mediante una conexión cifrada gracias a los certificados que se incluyen con la instalación del Pandora FMS server. Los ficheros que envía el agente RMM son los .data y .keepalive.

Los ficheros .data se enviarán al servidor únicamente cuando se hayan realizado ejecuciones de script en el intervalo de tiempo previo, donde se incluirán, así como en los ficheros .keepalive, el nombre de agente (agent_name), la fecha de contacto, el intervalo de tiempo del agente RMM, y la diferencia es la presencia de datos sobre la ejecución llevada a cabo. Se indicarán el ID de la ejecución, el paso donde finalizó la ejecución, el estado en formato numérico, el mensaje de salida (STDOUT) y el mensaje de error (STDERR):

{
  "agent_name": "4a6d4f8f8d599d57ba3b5b7c1c0bf4450306e720c5c46d9de2ef31daf3984dca",
  "last_contact": "1731402567",
  "rmm_interval": "30",
  "script": [
    {
      "queue_id": "60",
      "step": "post",
      "status": 0,
      "output": "Execution completed successfully\n",
      "error": ""
    }
  ]
}

Los ficheros .keepalive se envían en todos los intervalos del agente RMM e indicarán al servidor que el agente RMM se encuentra disponible/conectado. El contenido de estos ficheros incluye el nombre de agente (agent_name) para facilitar la vinculación con el agente correspondiente registrado previamente en la consola, un timestamp indicando la fecha exacta de envío de dicho fichero para funcionar a modo de fecha de último contacto, y el intervalo de tiempo que está siguiendo:

{
  "agent_name": "4a6d4f8f8d599d57ba3b5b7c1c0bf4450306e720c5c46d9de2ef31daf3984dca",
  "last_contact": "1731402285",
  "rmm_interval": "30"
}

En este punto, la comunicación entre agente y servidor RMM debería estar funcionando correctamente. Se puede comprobar accediendo al listado de Agentes RMM o vista Heatmap en la sección Management → RMM del menú lateral izquierdo de la Consola web.

En caso de que la conexión sea correcta entre agentes y RMM server, será mostrado un recuadro diferente por cada agente RMM en la vista de Heatmap, representado con un color o esquema de colores y una leyenda para interpretar el estado del agente RMM con base en dichos colores.

Desde la vista de Agent list se tiene el mismo sistema de colores para los estados del agente RMM, además de contar con datos adicionales como el nombre del agente, su dirección IP, su sistema operativo y versión y su descripción (en caso de tener).

En esta vista se tienen todos los scripts registrados en el entorno, así como información sobre ellos y la posibilidad de crear nuevos scripts, editar los ya existentes o borrarlos.

Para crear scripts se tiene el mismo formulario para editarlos. Si se pulsa sobre New script o sobre el nombre de alguno de los scripts existentes se abrirán para su creación o edición.

A cada script se le puede otorgar un nombre, una descripción, indicar sistema operativo en el que se usará o será compatible, además de la versión de dicho SO. Esta parte solamente es organizativa pues carece de limitación alguna a la hora de asignar ejecuciones a los agentes RMM.

También se deber indicar un grupo al que pertenecerá dicho script, y al lado veremos una opción llamada Notify before executing. En caso de estar habilitado, el agente que vaya a llevar a cabo una ejecución con este script reportará un estado success previo a la ejecución real del script. Esto es útil en casos donde el proceso del agente RMM se vería detenido y resultaría imposible reportar correctamente los datos de la ejecución de manera posterior a la misma, por ejemplo al hacer un reinicio del equipo. Este estado correcto se representará en la lista de colas, pero de manera distinta al estado correcto de una ejecución real finalizada, de manera que pueda ser fácilmente identificable. La columna de status mostrará un recuadro verde con franjas o líneas blancas.

La siguiente sección de Inputs permitirá posteriormente personalizar un poco más el script a la hora de crear las ejecuciones. Al hacer clic sobre Add input, se podrá dar un nombre, elegir un tipo entre string y resource, indicar un tip o ayuda sobre dicho input, y el valor de macro que tendrá dicho input, que se rellena automáticamente.

La diferencia entre los tipos string y resource radica en que con un input de tipo string, al crear una ejecución, se podrá indicar el valor de dicho input a mano y, como su nombre indica, sería una cadena de texto o caracteres.

Si en un script que haga un reinicio de un servicio se hace uso de input de tipo string, se podrá usar dicho script para multitud de servicios, simplemente indicando un servicio distinto para cada ejecución. Con los de tipo recurso, se podrá elegir el recurso que será usado por el script en cada ejecución. Para ello se necesita subir los recursos previamente, lo veremos más adelante.

Una vez se tiene configurada la parte de inputs, lo siguiente será la configuración del script como tal. Existen tres tipos de scripts:

• Precondition script.
• Script.
• Post script.

De estos tres tipos solamente será obligatorio contar con la configuración de script, localizado en el medio:

La estructura de configuración es la misma para los tres tipos. Se podrá indicar qué parámetros usará cada script en el campo Parameters indicando el nombre de macro visto en la sección de Inputs. En la sección de Interpreter se indicará qué intérprete de comandos será usado para la ejecución del script. Se pueden usar algunos tales como Bash, Python, Perl, … siempre teniendo en cuenta que deben estar instalados y disponibles en el entorno del agente.

En la parte de File extension se indicará la extensión del fichero del script y por último la parte de Code, donde se introducirá el código del script en sí. La extensión del fichero es especialmente importante en sistemas MS Windows®, ya que en caso de no indicarse el adecuado, los scripts no se ejecutarían de forma correcta.

Una vez se tenga el script configurado, solamente faltará pulsar sobre Update configuration para actualizarlo si lo estábamos editando o Save configuration si se trataba de la creación de uno nuevo.

En esta vista están los recursos subidos y que posteriormente podrán ser usados en las ejecuciones. Por defecto, esta vista no mostrará nada. Para ello se deben subir los recursos propios.

Se ha de seleccionar el fichero desde el explorador, dando clic sobre Select a file e indicando un nombre corto (short name) que funcionará a modo de identificador único del recurso. Al subir un recurso usando un short name que ya existe, se preguntará si se desea actualizar el recurso previo.

Estos recursos se almacenarán, al igual que las carpetas de keepalive y data, en el directorio de RMM indicado en el fichero de configuración del servidor bajo el nombre de res.

En la Consola web se visualizará de la siguiente manera:

Además se cuenta con la opción de borrar individualmente o de manera masiva dichos recursos. Estos recursos son los que se podrán utilizar como inputs en los scripts si se indica que el tipo del input sea Resource.

Para poder visualizar las vistas de Queues y Schedules de manera correcta se necesita añadir ejecuciones en algún agente, en caso contrario ningún contenido se tendrá para visualizar.

Para ello, desde Agent list o Heatmap se accede a la vista Agent details del agente que se elijas haciendo clic sobre su nombre. Vista por defecto sin ninguna ejecución creada:

Para agregar ejecuciones al agente bastará con pulsar sobre New execution y se abrirá el formulario de creación de ejecuciones.

Aquí se podrá usar el primer desplegable para filtrar según el sistema operativo que usemos (dato organizativo). Posteriormente, con el desplegable de Scripts se podrá elegir qué script usará la ejecución que se está creando.

Posteriormente se podrá indicar el nombre que tendrá la ejecución y su tipo de programación:

• Only once: Agregará la ejecución directamente en la cola, por lo que se ejecutará inmediatamente después de su creación y en cuanto el agente RMM lea en el servidor dicha ejecución. Se podrán ver en la vista de Queues.
• Schedule: Mostrará desplegables para seleccionar, en formato cron, cuándo se llevará a cabo dicha ejecución. Hasta que no se cumpla el tiempo indicado este tipo de ejecuciones no aparecerán en la vista de Queues más siempre serán visibles y con la opción de edición desde la vista Schedules.

Dependiendo del script elegido, aparecerán sus inputs, en caso de haberlos. Los de tipo string dejarán rellenar el texto como se necesita y los de tipo resource ofrecerán el listado de recursos RMM subidos en el entorno.

Además, si se rellenan el campo de Tip configurando los inputs, mostrará el mensaje de ayuda:

Después de terminar la configuración para la ejecución, pulsar sobre Confirm para guardar. Aparecerá listada en la vista Agent details:

Las ejecuciones se agruparán automáticamente por nombre de tarea y script, de manera que si hay ejecuciones en distinto tiempo que comparten nombre y script, sus historiales de ejecución se juntarán y serán visibles haciendo clic sobre el botón de Execution history que aparece en la columna de Actions de la tabla.

Por la parte de las ejecuciones programadas, aparecerán en la tabla inferior y solamente aparecerán sus ejecuciones encoladas cuando se haya cumplido el tiempo indicado en el apartado Cron.

En esta vista están todas las ejecuciones encoladas del entorno junto a una serie de datos que ayudarán a identificarlas.

Con una serie de filtros ayudarán a limitar los datos mostrados, como el de Free search (buscará en las columnas Task name, agent, script, step, output, error) y los filtros por scripts, status, last queue, step.

Además se cuenta con acciones en la tabla para abrir el detalle de la ejecución o bien borrarla de la cola. Si no se ha ejecutado aún, esto impedirá su futura ejecución. En caso de sí haberse ejecutado, simplemente se borrará tanto de la lista de ejecuciones del agente RMM como de la vista de la cola.

Para visualizar las ejecuciones programadas:

Se pueden hacer uso de filtros para buscar por agente, script o los horarios de cron especificados. También es posible editar las tareas o borrarlas.

Volver al índice de documentación de Pandora FMS