The commercial editions can update their agents on Linux, Windows and Solaris automatically. This feature enables easy updating of the agents in the case of new Checkmk versions, and even a changed configuration of the agents can be applied automatically. In this way you can take advantage of the Agent Bakery to apply individual configurations to hosts.
 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
Las ediciones comerciales pueden actualizar sus agentes en Linux, Windows y Solaris automáticamente. Esta función permite actualizar fácilmente los agentes en caso de nuevas versiones de Checkmk, e incluso aplicar automáticamente un cambio en la configuración de los agentes. De este modo, puedes aprovechar el Agent bakery para aplicar configuraciones individuales a los host.
1. Configurar las actualizaciones automáticas
La distribución automática de agentes está globalmente desactivada por defecto. Así que, antes de ocuparte de la configuración propiamente dicha, activa la opción Activation of automatic agent updates en Setup > General > Global Settings > Automatic Agent Updates:
Para poner en marcha las actualizaciones, sigue estos pasos: Primero abre Setup > Agents > Windows, Linux, Solaris, AIX y selecciona Agents > Automatic updates:
En Prerequisites encontrarás una lista de requisitos previos que deben cumplirse para que las actualizaciones automáticas funcionen correctamente. Puedes marcarlos por orden. No olvides que puedes obtener más información sobre cada uno de estos items a través de Help > Show inline help. Al hacer clic en te llevará directamente al item que debes configurar. En concreto, los ajustes descritos en los cinco capítulos siguientes deben realizarse y activarse a través de Master switch.
1.1. Crear una clave de firma
El sistema está diseñado para que los agentes puedan descargar actualizaciones a través de HTTP o HTTPS desde su servidor central de monitorización. Dado que los agentes contienen código ejecutable, es especialmente importante protegerse contra la posibilidad de que un atacante falsifique los agentes. Para ello se utilizan claves de firma, que consisten en un par de claves pública y privada (método de clave pública).
Puedes crear tantas claves de firma como quieras. Cada una de ellas está asegurada con una frase de contraseña, que posteriormente tendrás que introducir cada vez que firmes. Esto impide, por ejemplo, que un atacante que acceda a la copia de seguridad de un servidor de monitorización firme agentes.
Crea aquí una clave de firma y registra la frase de contraseña.
Importante: Esta frase de contraseña no puede cambiarse ni restaurarse posteriormente. Si se pierde la clave, puede significar que todos los agentes tengan que actualizarse manualmente de nuevo.
1.2. Configurar el Plugin de Actualización
La actualización propiamente dicha la realiza un plugin de agente llamado cmk-update-agent. El agente lo llama en un ciclo definible (por ejemplo, una vez por hora). En ese momento, pregunta al servidor de despliegue (tu sistema central de monitorización) si hay un nuevo paquete disponible para ese host y, en caso afirmativo, realiza la actualización.
Por supuesto, el Plugin debe estar presente y correctamente configurado en el agente. Para ello, amplía los agentes con este Plugin utilizando el conjunto de reglas Agent updater (Linux, Windows, Solaris). El conjunto de reglas se puede encontrar rápidamente, por ejemplo, en la página Automatic agent updates, en el menú Related > Agent updater ruleset.
Ten en cuenta que el conjunto de reglas sigue aquí el principio de "la primera regla por parámetro gana", lo que te permite definir ajustes básicos en general para no tener que establecerlos una y otra vez en las reglas más específicas. Además, la ayuda en línea proporciona más información sobre cada item en cuanto lo activas.
A continuación encontrarás algunas explicaciones sobre cada uno de los puntos.
Activación
Esta opción debe estar activada (Deploy plugin …) para permitir que el Plugin se añada al agente. Aquí, por ejemplo, se puede utilizar la herencia de reglas para establecer un valor predeterminado en una carpeta de nivel superior y anularlo para hosts/carpetas individuales según sea necesario.
Actualizar la información del servidor
Aquí se pueden introducir datos de configuración opcionales para la conexión del actualizador de agentes al servidor Checkmk. Si esta entrada no está configurada, la información deberá introducirse posteriormente al registrar el actualizador de agentes.
Carga
En el caso de monitorización distribuida con una configuración centralizada, el actualizador de agentes recibe por defecto su servidor de actualización correspondiente del site Checkmk al que se conecta. Esta opción se puede utilizar para configurar que el servidor de actualización introducido aquí se utilice de forma permanente y que se ignore el servidor de actualización automática.
Nombre DNS o dirección IP del servidor de actualización
Aquí introduces el nombre DNS con el que se puede acceder al servidor Checkmk. Es importante que el host que se va a monitorizar pueda resolver este nombre y que esté configurado como host en Checkmk. Ten cuidado cuando utilices HTTPS de que el nombre del certificado coincida con el nombre del servidor Checkmk conocido por el host.
Nombre del site Checkmk del servidor de actualización
Aquí introduces -salvo excepciones- el nombre del site en el que estás configurando esta regla. Una excepción a este planteamiento sería que los host afectados se "movieran" a otro site de Checkmk. En tal caso, por una sola vez, introduce aquí un site diferente. Véase también más abajo en Escenarios de aplicación. En una configuración distribuida con una configuración central, el site en el que quieres registrarte también puede ser diferente del site central en el que está configurada esta regla.
Protocolo a utilizar para obtener actualizaciones
Si -como recomendamos- utilizas HTTPS, debes asegurarte de que el actualizador de agentes también dispone de un certificado CA para verificar la conexión.
Importante: Dependiendo de la configuración del servidor, se puede forzar el uso de HTTPS (incluyendo el reenvío de HTTP a HTTPS). En tal caso, configurar esta regla en HTTP no tiene ningún efecto.
Certificados para la verificación HTTPS
Los certificados CA o autofirmados configurados aquí están a disposición del actualizador de agentes para la verificación de las conexiones HTTPS. Alternativamente, en el caso de una configuración distribuida con una configuración central, también se pueden poner certificados a disposición del actualizador de agentes desde el site Checkmk, o se pueden importar directamente durante la conexión mediante parámetros de la línea de comandos.
Importante: Si la cadena de certificados del servidor está firmada con una CA pública, la conexión puede verificarse normalmente sin certificados importados. Sin embargo, en cuanto el actualizador de agentes disponga de certificados importados de una de las fuentes mencionadas, ¡se ignorarán todas las demás autoridades de certificación de CA! En caso de problemas con la configuración de HTTPS, consulta la siguiente FAQ.
Intervalo para el check de actualización
Aquí se especifica el intervalo en el que el actualizador de agentes consulta al servidor de monitorización configurado si hay actualizaciones disponibles. Mientras no haya transcurrido el intervalo especificado, se devuelve una llamada en caché, para cargar lo menos posible la red. Normalmente, tiene sentido utilizar un intervalo no inferior a 10 minutos, ya que, de lo contrario, existe el gran peligro de que tu red se vea muy sobrecargada si tienes un gran número de agentes Checkmk. Si no estableces un valor aquí, se aplicará un valor por defecto de 1 hora.
Configuración del proxy
Esta configuración de regla también es opcional. El actualizador de agentes asume inicialmente que hay una conexión directa con el servidor Checkmk en el host de destino, incluso con configuraciones de proxy configuradas, e ignora todas las configuraciones de proxy locales. Si éste es el comportamiento deseado, esta configuración de regla puede omitirse. De lo contrario, introduce manualmente las configuraciones de proxy o utiliza las variables del entorno existentes en el host.
Formato del ejecutable (Linux)
Puedes especificar opcionalmente cómo se añade el Plugin al paquete de instalación del agente. El comportamiento por defecto de la regla depende del sistema de destino:
Linux (deb, rpm, tgz): No tienes que editar nada manualmente para estos sistemas; el actualizador de agentes se pasa como un binario de 64 bits. También puedes seleccionar opcionalmente un binario de 32 bits para sistemas heredados, o el antiguo script de Python.Importante: Para el binario necesitarás el paquete glibc (como mínimo la versión 2.5). Las distribuciones de Linux suelen cumplir estos requisitos desde 2006.
Windows: En los host Windows, Checkmk siempre distribuirá un ejecutable de 32 bits, por lo que esta regla se ignora por defecto.Nota: Si encuentras un binario de 64 bits del actualizador de agentes en alguno de tus host Windows, esta versión es anterior a Checkmk y no está actualizada.
Solaris: Tampoco tienes que modificar nada aquí. Checkmk utilizará el script de Python aunque dejes el valor por defecto en el binario de 64 bits.
Otras arquitecturas: Si tienes paquetes para otras arquitecturas como arm o ppc, establece esta opción manualmente en Python, ya que Checkmk no lo intercepta automáticamente y no se ofrecen binarios para estas plataformas.
Si aún necesitas confiar en el antiguo script de Python, se aplican los siguientes requisitos al sistema:
Python3 en versión 3.4 o posterior
Las solicitudes de los módulos Python, PySocks y pyOpenSSL
Claves de firma que aceptará el agente
Selecciona al menos una clave de firma cuya firma deba aceptar el actualizador de agentes. También puedes especificar opcionalmente varias claves. Este puede ser el caso si, por ejemplo, quieres desactivar una clave antigua. Para ello, el actualizador de agentes del host debe aceptar entretanto ambas claves.
Después de esta última configuración, tu regla podría tener el aspecto de la siguiente captura de pantalla. Guarda todas tus entradas haciendo clic en Save.
1.3. Preparar y firmar agentes
A continuación, puedes hornear y firmar inmediatamente los agentes configurados de esta forma en una sola acción. Esto se debe a que las reglas recién creadas y personalizadas no se encontrarán en los paquetes de instalación hasta que las hayas creado/horneado de nuevo. Navega hasta Setup > Agents > Windows, Linux, Solaris AIX y haz clic en Bake and sign agents. Ahora debes introducir la frase de contraseña de la clave que deseas utilizar. Después de hacer clic en Bake and sign, el procedimiento de horneado se iniciará como un proceso en segundo plano. Cuando este proceso haya finalizado, se te informará:
Todos los agentes firmados de esta forma serán asignados a una clave correspondiente. Si has creado varias claves, firma con estas claves adicionales por separado.
Importante: Basta con que el actualizador de agentes del host esté monitorizado si el nuevo paquete ha sido firmado con una de las claves conocidas por el actualizador.
1.4. Registrar el actualizador de agentes
En el siguiente paso se registran los host que se van a monitorizar en el servidor Checkmk. Como el servidor Checkmk aún no confía en un host nuevo, y el servidor aún no sabe que el host debe actualizarse automáticamente, el agente debe instalarse manualmente -una sola vez- en el host.
Para ello, ve primero a Setup > Agents > Windows, Linux, Solaris, AIX y descarga el paquete adecuado para el host desde Agent bakery. Asegúrate de que el paquete contiene realmente el Plugin de agente actualizador.
Registro del actualizador de agentes en Linux
Ahora copia el paquete del agente en el host e instálalo con rpm o dpkg (instalación de paquetes en Linux).
Tras la instalación, encontrarás el plugin del actualizador de agentes en el directorio /usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. El valor del subdirectorio 3600 indica el intervalo para el check de actualización en segundos (aquí para el valor por defecto de una hora). Un script con el mismo nombre también está almacenado en /usr/bin/, de modo que cmk-update-agent también está disponible como comando.
Ahora llama al actualizador de agentes con el argumento register. Introduce la información requerida en secuencia.
Con el siguiente comando, ya puedes registrar el actualizador de agentes desde un host Linux:
root@linux# cmk-update-agent register -v
-------------------------------------------------------------------
| |
| Check_MK Agent Updater v2.1.0 - Registration |
| |
| Activation of automatic agent updates. Your first step is to |
| register this host at your deployment server for agent updates. |
| For this step you need a user with the permission |
| "Register all hosts" on that Checkmk site. |
| |
-------------------------------------------------------------------
Our host name in the monitoring:
myhost
User with registration permissions:
cmkadmin
Password:
Going to register agent at deployment server
Successfully registered agent of host "myhost" for deployment.
You can now update your agent by running 'cmk-update-agent -v'
Saved your registration settings to /etc/cmk-update-agent.state.
Hint: you can do this in scripts with the command:
cmk-update-agent register -s myserver.example.com -i mysite -H myhost -p https -U cmkadmin -P * -vAlternativamente, puedes realizar el registro en modo no interactivo introduciendo los datos necesarios a través de las opciones de la línea de comandos. En Linux, una llamada al cmk-update-agent register --help aquí muestra las opciones configurables.
Registro del actualizador de agentes en Windows
Ahora copia el paquete del agente en el host e instálalo con msiexec (instalación de paquetes de Windows).
Tras la instalación, el actualizador de agentes se integra en el agente de Windows C:\Program Files (x86)\checkmk\service\check_mk_agent.exe. El propio actualizador puede controlarse con el comando check_mk_agent.exe updater.
Ahora llama al actualizador de agentes con el argumento register. En Windows, esto debe hacerse en un símbolo del sistema con derechos de administrador. Introduce la información requerida en secuencia.
Como el actualizador de agentes para hosts Windows está integrado en el propio agente, el comando para registrarlo tiene el siguiente aspecto:
C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" updater register
Using previous settings from C:\ProgramData\checkmk\agent\config\cmk-update-agent.state.
Our host name in the monitoring:
mywindowshost
User with registration permissions:
cmkadmin
Password:
Successfully registered agent of host "mywindowshost" for deployment.Alternativamente, puedes realizar el registro en modo no interactivo introduciendo los datos necesarios mediante las opciones de la línea de comandos. El comando completo para el registro tiene el siguiente aspecto:
C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" ^
updater register -s myserver.example.com -i mysite -H mywindowshost -p https -U cmkadmin -P mycmkadminpassword -vRegistro único e información general
El registro único también se puede realizar a través de un usuario de automatización. Para ello, en la línea de comandos se pasa el usuario a través de -U/--user y la contraseña de automatización a través de -S/--secret.
Algunas notas sobre el registro:
Al registrarse, el Plugin también necesita el nombre del host tal y como se conoce en la monitorización, que no tiene por qué coincidir con el nombre del host del ordenador. El nombre del host se almacena localmente junto con la clave.
Para utilizar HTTPS, también debe estar configurado HTTPS en tu servidor de monitorización. HTTP es mucho más sencillo en este caso, pero no proporciona encriptación de la transmisión. Dado que, en teoría, el agente puede contener contraseñas, HTTPS es el método recomendado. Sin embargo, la autenticidad del agente está garantizada independientemente por la firma.
El inicio de sesión como administrador de Checkmk sólo se requiere una vez. En el momento del registro, el agente y el servidor acuerdan una clave secreta(host secret) que sólo conoce este host. La contraseña del administrador de Checkmk no se almacena en ningún sitio.
Mientras que el modo interactivo sólo sondea los campos que aún no están en ninguna configuración, el modo no interactivo permite configurar todos los campos que se muestran en la ayuda y tiene la máxima prioridad para esta llamada. Las opciones que se guardan sólo en
cmk-update-agent.statese sobrescribirán - las opciones decmk-update-agent.cfg, sin embargo, no lo harán. Puedes encontrar más detalles sobre esto más adelante en Ver la configuración local.
Tras un registro correcto, el secreto del host se almacena en el agente en el archivo /etc/cmk-update-agent.state. En el servidor se encuentra en ~/var/check_mk/agent_deployment/myhost. A partir de ahora, el secreto del host permite al host descargar su propio agente del servidor sin necesidad de contraseña. No es posible descargar agentes de otros hosts, ya que podrían contener datos confidenciales.
1.5. Conmutador master
Ahora deberían cumplirse todas las condiciones. Si aún no ha ocurrido, actívalo pulsando en Master switch. La tabla Prerequisites debería tener ahora este aspecto:
A partir de ahora, el agente informará al final de cada intervalo de actualización configurado y buscará una nueva versión del agente. Si una nueva versión está lista-y firmada-se descargará e instalará automáticamente.
Al mismo tiempo, el Master switch es también una forma de desactivar globalmente el proceso de actualización.
También se ofrece una guía paso a paso en el vídeo que se originó en la Conferencia Checkmk nº 3 (2017), en el siguiente enlace. Ésta no es la última versión, pero el procedimiento básico no ha cambiado:Las nuevas actualizaciones automáticas del agente
2. Restringir las actualizaciones a determinados hosts
Antes de desplegar un nuevo agente en un gran número de hosts, seguramente querrás probarlo primero con un número menor de hosts. Este importante paso evita un posible error de graves dimensiones.
Para ello, utiliza la caja central de la página Automatic agent updates:
Se aplica una conjunción lógica(AND) a las condiciones: Sólo los hosts que coincidan con todos los criterios seleccionados recibirán la actualización. Después de establecer aquí las condiciones para seleccionar hosts, puedes utilizar el campo Test hostname before activation para introducir nombres del host individuales y comprobar si se han activado o no las actualizaciones para estos hosts.
Importante: En los hosts a los que aún no se les vayan a proporcionar actualizaciones automáticas, el paquete instalado no debe contener el plugin de agente actualizador - de lo contrario, el plugin te advertirá regularmente de que el host aún no ha sido registrado.
3. Diagnostica
Hay bastantes fuentes de información para diagnosticar si todas las actualizaciones funcionan según lo previsto.
3.1. Estadísticas de distribución de agentes
Esta vista general muestra cómo se comportan los hosts individuales en el actualizador de agentes. La ayuda en línea ofrece más explicaciones. Haciendo clic en se obtiene una lista detallada de los hosts individuales. También puedes acceder a la lista completa de todos los hosts registrados a través de la vista de Monitor > System > Agent update status. Allí puedes buscar hosts individuales.
En esta lista también encontrarás documentación sobre cómo se inicia el hash de un agente, qué agente está destinado a un host (Target Agent), qué agente se ha descargado más recientemente del host (Downloaded Agent) y qué agente está instalado actualmente en el host (Installed Agent). De este modo, siempre podrás ver si se han cumplido las especificaciones o dónde se encuentra actualmente el proceso. Hay que señalar aquí que la información sobre el estado aparece a la izquierda directamente en la comunicación entre el Agent bakery y el actualizador de agentes, mientras que los campos Update Check y Update Check Output proceden del plugin de agente al consultar al agente del host, y que debido al caché (definido por el intervalo de consulta) pueden actualizarse en un momento distinto.
3.2. El servicio Agente Check_MK
Si has instalado el plugin actualizador de agentes en un agente, éste emitirá regularmente el estado actual de la actualización en forma de datos de monitorización. El descubrimiento de servicios genera un nuevo servicio con el nombre Check_MK Agent en el host. Éste refleja de nuevo el estado actual de la actualización. De esta forma, se te puede notificar cualquier problema con las actualizaciones.
Entre otras cosas, el estado del servicio señala cómo se evalúa el estado de la clave de firma. Son posibles los siguientes estados
WARN: El certificado de la clave de firma está dañado, ya no es válido o será inválido en los próximos 90 días.
CRIT: No hay certificado válido para la clave de firma o el certificado perderá su validez en los próximos 30 días.
3.3. Vista de la configuración local
El comportamiento del actualizador de agentes se rige por los dos archivos cmk-update-agent.cfg y cmk-update-agent.state. Siempre se aplica que los valores definidos en el archivo .cfg anulan los del archivo .state. Si el actualizador de agentes muestra un comportamiento inesperado, a veces merece la pena echar un vistazo a la configuración. También es útil llamar al actualizador de agentes directamente desde la línea de comandos:
root@linux# cmk-update-agent show-config
Showing current configuration...
Configuration from config file (/etc/check_mk/cmk-update-agent.cfg):
server: myserver
site: mysite
protocol: http
certificates: []
ignore_update_url: False
interval: 3600
proxy: None
signature_keys: ['-----BEGIN CERTIFICATE-----\n [...] \n-----END CERTIFICATE-----\n']
use_proxy_env: False
Configuration from state file (/etc/cmk-update-agent.state):
last_error: None
host_secret: zqscykkqfdkpwnwenqfibdksqvuamblstbtmpasbhnlbubmncgmrqxvakasittxw
host_name: myhost
user: cmkadmin
last_check: 1660750511.8183599
pending_hash: None
installed_aghash: 94b60c8ef40c4900
last_update: 1660750584.85276533.4. Mensajes de registro
En caso de problema, también encontrarás datos de registro de las actualizaciones en el host a monitorizar. En Linux, cmk-update-agent registra información importante en syslog, como advertencias y errores:
Jul 02 13:59:23 myhost [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 13:59:23 myhost [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.En Linux y en Windows puedes encontrar un archivo de registro más detallado cmk-update-agent.log que incluye la salida de depuración y posibles rastreos:
2021-07-02 17:58:18,321 DEBUG: Starting Check_MK Agent Updater v2.0.0p9
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/cmk-update-agent.state.
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/check_mk/cmk-update-agent.cfg.
pass:q[...]
2021-07-02 17:58:18,387 INFO: Target state (from deployment server):
2021-07-02 17:58:18,387 INFO: Agent Available: True
2021-07-02 17:58:18,387 INFO: Signatures: 1
2021-07-02 17:58:18,387 INFO: Target Hash: 081b6bcc6102d94a
2021-07-02 17:58:18,387 INFO: Ignoring signature #1 for certificate: certificate is unknown.
2021-07-02 17:58:18,388 DEBUG: Caught Exception:
Traceback (most recent call last):
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1733, in main
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 714, in run
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1372, in _run_mode
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1071, in _do_update_as_command
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1150, in _do_update_agent
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.En ambos sistemas también puedes utilizar la opción de línea de comando --logfile LOGFILE para especificar una ruta alternativa para el archivo de registro.
4. Escenarios de aplicación
4.1. Desactivar las actualizaciones automáticas de host
Si hay que eliminar un host de las actualizaciones automáticas, modifica su configuración con el conjunto de reglas Agent updater (Linux, Windows, Solaris) para que allí se desactive el Plugin de actualización. En la siguiente actualización regular, ¡el propio agente eliminará su propio actualizador!
Ni que decir tiene que la actualización sólo puede reactivarse mediante la instalación manual de un nuevo paquete de agente. El registro se mantiene y no es necesario renovarlo.
4.2. Migrar a un nuevo site de monitorización
Si quieres trasladarte a un nuevo site Checkmk en una configuración de site único sin perder los hosts registrados en el servidor, debes tener en cuenta que, para que el proceso de actualización de agentes se realice correctamente, deben coincidir los siguientes datos del servidor y del host:
El nombre con el que se monitoriza y registra el host.
El secreto del host, que se asignó automáticamente durante el registro.
La firma utilizada para firmar los agentes.
Para conseguirlo, sigue estos pasos:
Primero añade a la monitorización todos los host cuya información de registro se vaya a migrar al nuevo site. Asegúrate de que los host del nuevo site se monitorizan con el mismo nombre. A continuación, copia la carpeta
~/var/check_mk/agent_deploymentdel antiguo al nuevo site de monitorización.Exporta la(s) clave(s) de firma aceptada(s) por los agentes instalados en los host. Las claves de firma se pueden exportar e importar utilizando Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Signature keys.
Importa estas claves de firma del paso 2 en el nuevo site de monitorización.
Configura la regla del actualizador de agentes en el nuevo site de monitorización según las instrucciones, y firma los agentes horneados con la(s) clave(s) de firma importada(s).
Por último, en la regla del actualizador de agentes del sitio antiguo, configura los campos del servidor de actualización y el nombre del sitio Checkmk conforme a tu nuevo sitio de monitorización, y vuelve a hornear los agentes. Nota: Comprueba en este punto que has especificado todo correctamente antes de volver a preparar los agentes.
En cuanto las próximas actualizaciones automáticas pasen por los host, el antiguo site de monitorización quedará bloqueado. A partir de ese momento, los host a monitorizar sólo responderán al nuevo servidor Checkmk. Tras la segunda actualización automática, el agente será instalado por el nuevo servidor Checkmk en consecuencia.
4.3. El actualizador de agentes como instalador automático
Atención: Ésta no es una función oficial del actualizador de agentes, por lo que estas instrucciones están dirigidas principalmente a usuarios con más experiencia. La forma oficial de instalar un agente Checkmk en un host es descargar y ejecutar el paquete de agente adecuado para el sistema. Sin embargo, también es posible permitir que el agente Checkmk se instale inicialmente mediante el actualizador de agentes, ya que éste también funciona como un programa independiente.
Procede como sigue:
Copia el binario cmk-update-agent o el script
cmk_update_agent.pyen el host que se va a monitorizar (ambos se encuentran en~/share/check_mk/agents/pluginsen el servidor Checkmk).Registra el host en el servidor Checkmk invocando
cmk-update-agent register. Aquí tiene sentido pasar la información de registro necesaria directamente a través de la línea de comandos, sobre todo si quieres utilizar un script de instalación. Las opciones correspondientes se pueden mostrar al llamar acmk-update-agent register --help.A continuación, con una última llamada al plugin de actualizador de agentes, instala el agente con todos los detalles de configuración del host que se está monitorizando. Sin embargo, como no hay configuración local (el actualizador de agentes también muestra la advertencia correspondiente), y por tanto no hay firma para el paquete del agente que se va a descargar, llama al actualizador una vez más con
cmk-update-agent --skip-signaturespara confiar explícitamente en el paquete descargado. El requisito previo para la instalación mediante el actualizador de agentes es, por supuesto, que el Agent bakery tenga listo un paquete de agentes adecuado para el host de destino en el servidor Checkmk.
5. Actualización de agentes en monitorización distribuida
Desde Checkmk 2.0.0 también es posible distribuir agentes horneados a través de sites remotos. El requisito previo para ello es una instalación con una configuración centraly una conexión que permita llegar al site central desde los sites remotos mediante HTTP/HTTPS.
Una monitorización distribuida de este tipo también puede funcionar, sobre todo temporalmente, con distintas versiones de Checkmk. Esto permite cambiar sucesivamente sistemas más grandes a una nueva versión de Checkmk. En este caso, sin embargo, asegúrate de seguir las notas sobre entornos de monitorización de versiones mixtas en la monitorización distribuida.
5.1. Funcionalidad
Técnicamente, la función está implementada de tal forma que las solicitudes de actualización de los sites remotos se reenvían al site central, de forma que toda la configuración, así como la cocción de los agentes, tiene lugar exclusivamente en el site central. Los paquetes de agentes que ya han sido solicitados en un site remoto se almacenan en caché en el site remoto (siempre que sean válidos), de forma que no sea necesario volver a descargar los paquetes desde el site central. Además, se comprobará la coherencia de los datos solicitados en el site remoto, para evitar conexiones innecesarias al site central.
A diferencia de lo que ocurre en una configuración de sitio único, el servidor de actualización adecuado para los hosts no se origina exclusivamente a partir del conjunto de reglas para el actualizador de agentes, sino que es comunicado al actualizador de agentes solicitante por el sitio Checkmk contactado. En este proceso, el sitio desde el que se monitoriza proporciona a un host su servidor. Por tanto, la especificación de un servidor Checkmk sólo es necesaria para el registro único, que teóricamente puede tener lugar en cualquier site -accesible desde el host- de todo el sistema de monitorización distribuida. Si falla la conexión con el servidor determinado automáticamente, se utiliza como reserva el servidor guardado previamente (desde la configuración de reglas o introducido manualmente con anterioridad durante el registro).
5.2. Configuración
La distribución de paquetes de agentes a través de sites remotos no tiene que activarse por separado - el site remoto respectivo reconoce la situación automáticamente y se comunica en consecuencia con el site central, así como con el actualizador de agentes solicitante. Si los agentes deben informar explícitamente sólo al site central para las actualizaciones, esto puede hacerse a través de un servidor de actualización fijo en elconjunto de reglas para el Actualizador de Agentes.
Sin embargo, para que las actualizaciones de agentes funcionen realmente en una monitorización distribuida, deben realizarse algunos ajustes en el site central, todos los cuales pueden encontrarse en Setup > General > Global Settings > Automatic Agent Updates. Si los ajustes difieren para cada site remoto, pueden editarse en Setup > General > Distributed monitoring > (Site specific global settings).
Conexión con el Agent bakery central
En este punto, se debe especificar la URL a través de la cual se puede acceder al site central desde el site remoto, incluyendo su protocolo y la cadena de caracterescheck_mk, por ejemplo https://myserver.org/mysite/check_mk. Aunque el site Checkmk intentará identificar por sí mismo el resto de configuraciones que falten, la especificación de esta URL no es opcional, ya que de lo contrario no se establecerá esta dirección de conexión en el caso de una configuración central. Si el protocolo es HTTPS, el site remoto utiliza automáticamente los certificados CA o autofirmados disponibles en la configuración para la verificación de la conexión Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL. El site remoto también requiere un usuario de automatización creado previamente para poder conectarse al site central. Esto también puede seleccionarse aquí. Si no se especifica ninguno, el site remoto busca un usuario de automatización con el nombre "Automatización".
Conexión a la Agent bakery remota
Como los sites remotos no son necesariamente accesibles desde los respectivos host monitorizados a través de la misma URL que desde el site central, se puede configurar aquí una URL para este fin. Esta URL se comunica automáticamente al host (o al actualizador de agentes solicitante) cuando se realiza una conexión a un site Checkmk. La configuración como ajuste global específico del site tiene especial sentido en este caso. Si no se especifica ninguna URL, se asume que los sites remotos son accesibles tanto desde el site central como desde los hosts monitorizados bajo la misma URL. Si se trata de una conexión HTTPS, también se puede poner automáticamente a disposición del host el certificado adecuado. Como para esto no se puede utilizar el almacén central de CA, en este punto se pueden especificar los certificados apropiados. Como alternativa, también se pueden especificar los certificados en las reglas del actualizador de agentes.
6. Trabajar con HTTPS
En varios puntos de este artículo se hace referencia a la seguridad de las conexiones respectivas mediante HTTPS. Aquí, una vez más, proporcionaremos una visión general de lo que hay que hacer para asegurar completamente las conexiones mediante HTTPS. Tanto la conexión de un site remoto a su site central, como la de un host a un site Checkmk pueden y deben asegurarse mediante TLS, es decir, utilizando HTTPS. Esto es independiente de si se trata de una configuración de site único o de una configuración distribuida.
6.1. Configurar HTTPS
Para poder conectarse a un site Checkmk mediante HTTPS, primero hay que configurar el servidor de monitorización para HTTPS. Esto se puede conseguir, por ejemplo, mediante una configuración adecuada del sistema Apache o, más sencillamente, mediante los ajustes HTTPS del appliance Checkmk.
La dirección HTTP o HTTPS del servidor Checkmk viene determinada por la URL configurada en cada caso. Si empieza por https://, la dirección del servidor es el protocolo HTTPS a través del puerto 443. Esto también se aplica al protocolo que hayas configurado con el parámetro Update server information En principio, puedes forzar el reenvío de HTTP a HTTPS en el lado de Apache y excluir (inicialmente) rutas individuales para ello. Para más detalles sobre la configuración, consulta la documentación de Apache para los módulos mod_rewrite y mod_redirect.
6.2. Proporcionar certificados
Para que se establezca una conexión HTTPS, debe ser posible verificar la cadena de certificados del servidor contactado o el certificado autofirmado (dependiendo de cómo esté configurado el servidor). La provisión de certificados CA o autofirmados adecuados lo hace posible y puede realizarse de varias formas.
Conexiones desde un host a un servidor Checkmk
El actualizador de agentes siempre intenta verificar las conexiones HTTPS y las cancela si no es posible realizar la verificación. El actualizador de agentes dispone de certificados para la verificación de las siguientes fuentes:
El Actualizador de Agentes:Por defecto, el Actualizador de Agentes viene con un entorno de ejecución Python que incluye todos los módulos necesarios. También se incluye el paquete de certificados del módulo Certifi, que a su vez se basa en la colección de certificados del proyecto Mozilla. Esto garantiza que las CA públicas se dan a conocer al Actualizador de Agentes en el momento oportuno, incluso cuando hay actualizaciones pendientes del sistema operativo.
Certificados a través del Agent bakery:Los certificados contenidos en el módulo Certifi se ignoran una vez que se han importado uno o más certificados a través de uno de los siguientes mecanismos. Los certificados de las siguientes fuentes se almacenan localmente en el host y sólo los utiliza el actualizador de agentes:
Utilizando la opción Certificates for HTTPS verification los certificados pueden incorporarse a un paquete de agente y estarán disponibles para el actualizador de agentes desde la instalación (o una actualización).
Al configurar la conexión con el site remoto a través de Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery, puedes especificar certificados que puedan utilizarse para verificar la conexión HTTPS con el site remoto respectivo. Esto es especialmente útil si en el momento de la configuración aún no está claro qué host se asignará a qué site. Esta opción de importación también puede utilizarse para reducir el número de agentes que hay que bakear, ya que no es necesario configurar específicamente en el host los certificados correctos para los servidores de actualización respectivos.
Almacéndecertificados:el actualizador de agentes puede utilizar el almacén de certificados del sistema operativo sólo si el actualizador de agentes se ha configurado para utilizar el System-Python en lugar del entorno de ejecución Python suministrado, y no se ha configurado ningún módulo Certifi en el System-Python. Dado que aquí intervienen muchos factores, como los parámetros de instalación o la variable del entorno _PIP_STANDALONE_CERT, no admitimos oficialmente dicha configuración.
Certificado a través de la línea de comandos - Importar certificado:También puedes llamar al actualizador de agentes con el argumento de la línea de comandos --trust-cert. Esto recupera e importa el certificado del servidor. Esto se hace sin tener en cuenta el tipo de certificado: Se confía en el certificado sin más check de una posible cadena - independientemente de si es un certificado autofirmado, un certificado al final de una cadena de certificados públicos o un certificado firmado con una CA interna.
|
|
Certificado a través de la línea de comandos - Ignorar certificado:Si el actualizador de agentes no dispone de ningún certificado válido, se puede omitir la validación del certificado utilizando el argumento de la línea de comandos --insecure para una llamada. Esto puede ser útil si el certificado válido ya está esperando a ser recuperado del servidor en la siguiente conexión, pero el actualizador de agentes quedará "bloqueado" por este certificado que falta.
|
En realidad, esto desactiva completamente el check del certificado para esta llamada. La comunicación sigue teniendo lugar de forma encriptada, por lo que el uso de este argumento es 'mejor que nada'. |
Conexión de un site remoto a un site central
La distribución de certificados es más sencilla cuando se conecta desde un site remoto al site central, ya que no se sale en absoluto del procedimiento de configuración. El site remoto puede utilizar el almacén de certificados Checkmk en Global settings > Site management > Trusted certificate authorities for SSL. Por tanto, basta con importar el certificado o certificados a través del site central, si es necesario también a través de Site specific global settings cuando el site central es accesible en varias URL.
Procedimiento para sustituir un certificado
Si trabajas con tu propia infraestructura de certificación, lo ideal es que utilices un certificado raíz que sea válido durante mucho tiempo y cuya clave asociada se utilice regularmente para crear certificados intermedios. En este caso, despliegas los certificados intermedios como una cadena de certificados en el servidor Checkmk. Los host que reciben las actualizaciones automáticas de los agentes ahora sólo necesitan conocer el certificado raíz.
Si no estás seguro de si un nuevo certificado de servidor requiere un nuevo certificado raíz, utiliza el siguiente comando. Utilízalo para determinar el identificador de la clave raíz utilizada para firmar un certificado de servidor:
root@linux# openssl x509 -noout -text -in cert.pem | grep -A1 'X509v3 Authority Key'
X509v3 Authority Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6Si el identificador mostrado es idéntico para el certificado antiguo y para el nuevo, no es necesario realizar ninguna otra acción. Los hosts que confían en este certificado raíz pueden seguir obteniendo actualizaciones aunque cambie la cadena del certificado, siempre que la cadena se haya almacenado correctamente en el sistema Apache.
Si hasta ahora se ha utilizado un certificado autofirmado o un certificado raíz de corta duración de una CA interna, o si la clave raíz anterior de una de tus CA internas se ha visto comprometida, procede como se indica a continuación al sustituir el certificado:
Añade el nuevo certificado utilizando el parámetro Certificates for HTTPS verification (en la regla Agent updater (Linux, Windows, Solaris) ).
Vuelve a crear los paquetes del agente y actualiza todos los hosts de la monitorización. Asegúrate de que esta actualización se ha ejecutado para todos los hosts antes de continuar.
Ahora sustituye el certificado del servidor.
Prueba con algunos host en los que sea fácil reinstalar el agente manualmente si falla, para ver si es posible actualizar de nuevo utilizando el nuevo certificado.
Si el paso anterior (4) se pudo realizar con éxito - puedes (el certificado caducará), o debes (la clave estaba comprometida) - elimina el certificado antiguo y realiza otra actualización del agente.
7. Solución de problemas
7.1. Errores típicos y sus soluciones
Errores ya solucionados en el servicio del agente Checkmk
En realidad, el actualizador de agentes sólo se ejecuta una vez dentro del intervalo de actualización, por lo que se mostrará un error de forma continua hasta que llames al Plugin manualmente o esté pendiente el siguiente intervalo.
El registro falla tras una reinstalación manual del agente Checkmk
El actualizador de agentes crea su propio archivo de estado cmk-update-agent.state de forma independiente (en Linux/Unix en /etc, y en Windows en la carpeta config ). Este archivo permanece en el host tras la desinstalación, para que no se pierda la información del registro. Una nueva instalación encontrará el archivo y seguirá utilizándolo. Si esta situación no es deseable, basta con borrar manualmente el archivo cmk-update-agent.state tras una desinstalación.
Estado de actualización para host sin actualizaciones automáticas activas
La página Monitor > System > Agent Update Status muestra todos los host que están en monitorización y para los que existe un archivo de estado en el servidor Checkmk. No importa si el host informa al servidor Checkmk de las actualizaciones automáticas. Si se muestra aquí un host inesperado, merece la pena echar un vistazo en la carpeta /omd/sites/mysite/var/check_mk/agent_deployment- la causa será probablemente un registro antiguo o creado accidentalmente.
La conexión a través de SSL/TLS no funciona
El actualizador de agentes está diseñado para confiar explícitamente sólo en los certificados que suelen especificarse en Agent updater (Linux, Windows, Solaris) en laconfiguración HTTPS. En particular, se ignoran los certificados instalados localmente. También puede ocurrir que el servidor Checkmk sea accesible a través del navegador, mientras que el actualizador de agentes no pueda conectarse debido a una configuración incorrecta.
En la configuración HTTPS de la regla del actualizador de agentes debe especificarse un certificado raízcon el que pueda verificarse la conexión con el servidor Checkmk. En otras palabras: la cadena de certificados incluida en elcertificado del servidor Checkmk debe poder verificarse con el certificado que se indique aquí. A menudo se especifica aquí en su lugar el certificado del servidor, pero esto no es adecuado para este fin.
Echa un vistazo a la cadena de certificados del servidor Checkmk con la herramientaOpenSSL. Debido a la longitud de la cadena, para mayor claridad aquí sólo se muestra una sección relevante y las secciones omitidas se marcan con [...]:
root@linux# openssl s_client -connect mymonitoring.example.net:443
[...]
subject=/CN=mymonitoring.example.net
issuer=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3832 bytes and written 302 bytes
Verification: OK
---
[...]Para la última entrada -en nuestro casosubject=/CN=mymonitoring.example.net- necesitas un certificado raíz válido. Éste no debe ser necesariamente -como en este ejemplo- el emisor del certificado. Normalmente será una cadena de emisores.
A continuación, fíjate en el certificado utilizado. También aquí, debido a su longitud, se acortará como en el ejemplo anterior:
root@linux# openssl x509 -text -noout -in myca.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 38 (0x26)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
Validity
Not Before: Jul 9 12:11:00 1999 GMT
Not After : Jul 9 23:59:00 2019 GMT
Subject: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
[...]
X509v3 extensions:
[...]
X509v3 Basic Constraints:
CA:TRUE, pathlen:5
[...]El certificado superior -que se ve en el extracto anterior- no puede depender de otro certificado. Puedes ver que el emisor(Issuer) y el item(Subject) son idénticos y que se incluye la opción CA:TRUE. Además, la cadena del emisor que autentifica un objeto debe ser coherente hasta la entrada final, por lo que también necesitas todos los certificados intermedios si el emisor del último certificado no es una CA.
Mensaje de error: No se puede abrir el auto cmk-update-agent ni el archivo cmk-update-agent.pkg
En algunos sistemas Linux se instala el programa Prelink y se activa un cronjob que examina regularmente todos los archivos binarios del sistema, y los adapta si es necesario para acelerar los programas. Sin embargo, el Plugin de agente actualizador está empaquetado con el programa PyInstaller, que no es compatible con este tipo de acciones, por lo que está averiado. Por tanto, Checkmk tiene una entrada en la lista negra de paquetes deb/rpm que se almacena en/etc/prelink.conf.d, y -si existe prelink- establece una entrada en el archivo /etc/prelink.conf existente. Como este problema es difícil de manejar, aún puede ocurrir que estas medidas no surtan efecto, especialmente en el caso de una instalación posterior de prelink.
Por lo tanto, si instalas prelink posteriormente, establece tú mismo la entrada y añade la siguiente línea al archivo con el siguiente comando:
root@linux# echo "-c /etc/prelink.conf.d/cmk-update-agent.conf" >> /etc/prelink.confMensaje de error cmk-update-agent: error al cargar bibliotecas compartidas: libz.so.1: no se ha podido mapear el segmento del objeto compartido.
Este mensaje de error se produce cuando se ha montado en el sistema el directorio /tmp con la banderanoexec. Para solucionar este problema, puedes eliminar la bandera o -si la has establecido y requerido deliberadamente- en el servidor Checkmk en Setup crear una regla enAgents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, UNIX). Allí puedes definir tú mismo el directorio tmp en la opciónDirectory for storage of temporary data (set TMPDIR environment variable). El plugin de actualizador de agentes escribirá entonces en el futuro archivos temporales en el directorio definido. Esto funciona incluso si llamas al Plugin manualmente con el script helper en /usr/bin/cmk-update-agent.
La instalación de RPM falla en Red Hat Enterprise Linux/CentOS
Ocasionalmente ha ocurrido -especialmente en sistemas RedHat/CentOS- que la llamada a rpm desencadenada por la actualización automática falla repetidamente, mientras que una llamada manual a cmk-update-agent procesa con éxito. La causa en estos casos era una directiva de SELinux que impedía una llamada sin errores si rpm era llamado por un proceso hijo de xinetd. Puedes solucionar el problema, es decir, llegar al fondo del asunto analizando los registros de SELinux y ajustando la directiva en consecuencia mediante la herramienta audit2allow.
Mensaje de error: No se ha encontrado una firma válida
Si el servicio Check_MK Agent muestra la advertencia No valid signature found, significa que el paquete del agente destinado al host en el Agent bakery no ha sido firmado con una de las claves aceptadas.
En el caso más sencillo, todo lo que tienes que hacer es firmar tus agentes utilizando la función Sign agents de la Agent bakery con una de las claves que se muestran en Signature keys the agent will accept.
En cuanto el actualizador de agentes realice su siguiente informe desde el host afectado al servidor Checkmk, y el intervalo de caché del servicio haya expirado, el aviso desaparecerá.
Sin embargo, si el host no tiene (o ya no tiene) una clave de firma única que se encuentre en el servidor Checkmk, deberás repetir el bakeado y firmar con una clave que aparezca en Signature keys the agent will accept, luego copiar el agente bakeado al host afectado y reinstalarlo allí.
En un host afectado, puedes ejecutar cmk-update-agent -v o check_mk_agent.exe updater -v para obtener más detalles sobre este error. El mensaje de error detallado enumera explícitamente las firmas del archivo de configuración del plugin de actualizador de agentes que no tienen una contrapartida aceptada (es decir, configurada) en tu servidor Checkmk.
Ignoring signature #1 for certificate: certificate is unknown.
No valid signature found.8. Archivos y directorios
8.1. Rutas de archivos en el servidor Checkmk
| Ruta del archivo | Descripción |
|---|---|
|
Contiene los agentes horneados, ordenados primero en subdirectorios por sistema operativo (por ejemplo, |
|
Contiene archivos con los nombres de los host registrados. Uno de estos archivos contiene la hora del último registro y el secreto del host. |
8.2. Rutas de archivos en el host Linux/Unix monitorizado
| Ruta del archivo | Descripción |
|---|---|
|
El plugin de actualizador de agentes como binario o script, dependiendo de la configuración en formato ejecutable. El subdirectorio |
|
Script para llamar al plugin de actualizador de agentes y registrar el agente con el comando |
|
Archivo de configuración del Plugin de actualizador de agentes, que contiene la configuración de la regla Agent updater (Linux, Windows, Solaris). No edites este archivo, porque se escribe en él durante las instalaciones y actualizaciones. |
|
Archivo con información del registro, incluido el secreto del host. |
|
Extenso archivo de registro con mensajes DEBUG |
8.3. Rutas de archivos en el host Windows monitorizado
| Ruta del archivo | Descripción |
|---|---|
|
Plugin actualizador de agentes como archivo Python |
|
Programa del agente para registrar el agente con el comando |
|
Archivo de configuración del Plugin actualizador de agentes |
|
Archivo con información del registro, incluido el secreto del host |
|
Archivo de registro detallado con mensajes DEBUG |
|
Fichero de configuración creado por el Agent bakery, que entre otras cosas define el intervalo para el check de actualización. |