Esta es la parte final del artículo, aquí está el comienzo.
La última vez que escribí sobre cómo implementé el monitoreo de dispositivos, ahora hablaremos sobre la administración. En conversaciones con "técnicos" por parte del Cliente, a menudo me encuentro con una percepción limitada de las capacidades de dispositivos tan pequeños (con bajos recursos de memoria y rendimiento), muchos creen que "lo máximo que necesitamos es enviar un reinicio , para algo más serio, enviaremos una brigada".
Pero la práctica demuestra que esto no es del todo cierto. Aquí hay una pequeña lista de tareas típicas comunes:
- Diagnóstico y solución de problemas de red. Detrás del puerto ethernet de su enrutador, generalmente "vive" otra pieza de hierro, que tiene su propia dirección IP interna. A veces, puede (debe) ser "ping". O administración de túneles: si el túnel de repente no se eleva en el enrutador que funciona a través del módem 3G, pero vemos el enrutador en sí.
- servicio del sistema. Actualización de firmware, actualización de scripts de servicio.
- Equilibristas. Esto podría llamarse "perversiones", pero el concepto de "caminante en la cuerda floja" como, cito, "la capacidad de un artista de circo para mantener el equilibrio en una posición corporal inestable" - se adapta mejor. Tales situaciones surgen debido al presupuesto limitado del cliente. Di un par de ejemplos a continuación, pero dado que no tienen relacion directa con el tema de la historia, los pongo en las notas
monitoreo wifiUn tema de moda desde hace cinco años, principalmente entre las cadenas minoristas federales. Está caminando lentamente por los pisos de negociación y su teléfono móvil con Wi-Fi encendido, en un intento de "pegarse" a algún hilo de la red, envía regularmente paquetes de solicitud de sonda que se pueden analizar para calcular por usted. : con qué frecuencia viene a esta tienda, por qué trayectorias camina, etc. Además, los datos se recopilan, analizan, se dibujan mapas de calor y los gerentes "eliminan" dinero de la gerencia o los inversores para tales imágenes. Mientras tanto .... "no hay dinero, pero aguanta ...", y el resultado (real) ya debería mostrarse, la buena vieja canción "Sí, sí, entonces, por supuesto, vamos a suministrar cisco y lo que quieras, ¡pero ahora tenemos que mostrarle al Cliente el resultado! Por cierto, se les olvidó decir que el Cliente permitía conectar nuestros equipos a su hotspot vía wifi, pero de forma general, como si fuéramos clientes invitados. Y ahora tiene que hacer enrutadores equilibrados: se levantan varias subinterfaces WiFi, una de las cuales se adhiere al punto de acceso, y la segunda monitorea el entorno, descarga frenéticamente el resultado de tcpdump en sí mismo, luego empaqueta el contenido del archivo en un archivo y corre el riesgo de morir por "comer en exceso" tratando de escupir el contenido al servidor ftp. No es sorprendente que el enrutador equilibrador a menudo se “descomponga” y de alguna manera tenga que ser “reanimado” de forma remota.
Radio de busquedaAquí es más fácil describir la situación con algo como esta declaración del cliente: “Queremos una red descentralizada de puntos de acceso que funcionen en equipos cuyo modelo no se conoce de antemano, a través de canales, pero cuáles aún no conocemos. Ah, nos olvidamos de decir que no solo queremos mostrar anuncios a los clientes, sino también analizar todo lo relacionado con el sitio de instalación del punto de acceso. No, aún no sabemos por qué, pero se nos ocurrirá, no lo duden, se nos ocurrió esta idea”.
Y no debemos olvidar que debido a muchas circunstancias inciertas de antemano, la gestión debe realizarse en condiciones no estándar, cuando no podemos conectarnos al enrutador directamente a través del puerto ip: y nos vemos obligados a simplemente esperar a que aparezca actividad desde él. Si hacemos abstracción, entonces el diálogo entre el servidor y el enrutador se puede representar así:
- Router: Hola. Soy tal o cual enrutador, ¿hay alguna tarea para mí?
- Servidor: tal o cual enrutador, te registré que estás vivo. Aquí está el desafío: muéstrame el resultado del comando ifconfig.
- Router: Hola. Soy tal o cual enrutador, la última vez que pediste mostrar el resultado de ifconfig, aquí está. ¿Hay tareas para mí?
- Servidor: tal o cual enrutador, te registré que estás vivo. No hay tareas para ti.
La pregunta más interesante es: ¿cómo puede un enrutador remoto enviar cierta cantidad de información? En la última parte, describí que el enrutador, debido a los recursos limitados, solo tiene un wget "desmontado", que funciona solo a través de GET y nada más, no hay cliente ftp ni curl. Más precisamente, necesitamos una forma universal, independientemente de las características del conjunto de imágenes. Me decidí por usar wget. Más precisamente, cómo "detuve": simplemente no tuve otra opción 🙂
reserva inmediataMi solución de gestión está funcionando, no muy limitada, y estoy seguro de que está torcida, incluso si se adapta a la mayoría de mis clientes. ¿Cómo sería posible hacerlo sabiamente? Escriba una pequeña utilidad que envíe datos binarios a través de POST a través del puerto 80. Inclúyalo (utilidad) en el firmware del enrutador y use bash para acceder a él. Pero la realidad es que: a) necesita hacerlo rápidamente b) probablemente necesite hacer todo en el "zoológico de enrutadores" existente c) "¡no haga daño!" - si el enrutador está funcionando y realizando otras tareas, intente realizar cambios que no afecten la funcionalidad existente.
Pasemos a la implementación. Digamos que su cliente quiere que zabbix reinicie el enrutador de manera fácil y natural, con un "clic del mouse". Hoy comenzaremos la descripción de la implementación con zabbix.
En el menú "Administración" -> "Scripts" agregue un nuevo script. Lo llamamos "Reiniciar", como comando escribimos "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Siguiente: Menú "Monitoreo" -> "Últimos datos" -> "Haga clic derecho en el host deseado". Así es como se verá el menú después de agregar el script.
En consecuencia, colocamos el script reboot.php en el directorio /usr/share/zabbix (puede ser diferente para usted, yo uso el directorio raíz de zabbixa).
Descargo de responsabilidad de seguridadPara mayor claridad de la explicación en el guión, solo uso la identificación del enrutador, pero no uso la contraseña. ¡En la versión de trabajo, esto no se recomienda! ¿Por qué hice esto? Porque la gran pregunta es dónde almacenar las contraseñas de los enrutadores. ¿En zabbixe mismo en "inventario"? Práctica contradictoria. Como opción: restrinja el acceso externo al propio archivo reboot.php
archivo de reinicio.php
<?php
// присваиваем параметры с консоли переменным
$user = $argv[1];
// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля.
//$password = $argv[2];
$conn=new mysqli("localhost","db_user","db_password","db_name");
if (mysqli_connect_errno()) {
exit();
}
$conn->set_charset("utf8");
// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>En realidad todo. La pregunta "cómo obtener el resultado de la ejecución del comando desde el lado del dispositivo" permanece abierta. Consideremos la tarea usando el comando ifconfig como ejemplo. El siguiente comando se puede enviar al dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, donde:
mensaje=`ifconfig` - asignamos el resultado de la salida del comando ifconfig a la variable $message
obtener " - nuestro script a.php que registra enrutadores y recibe mensajes de ellos
u=usuario&p=contraseña!&m=$mensaje - credenciales y el valor de la variable de consulta m - asigna el contenido de la variable $message
-O /tmp/salida.txt - no necesitamos la salida al archivo /tmp/out.txt en este caso, pero si no se especifica este parámetro, wget no funciona
¿Por qué esto funciona mal?Porque es un potencial agujero de seguridad. el error más inocuo que puede ocurrir es si la salida de su comando, por ejemplo, contiene el símbolo "&". Por tanto, es necesario filtrar todo lo que se envía desde los routers y todo lo que llega al servidor. Sí, me da vergüenza, de verdad. En mi defensa, solo puedo escribir que todo el artículo está dedicado a cómo administrar enrutadores con firmware indefinido, con canales de comunicación indefinidos.
Bueno, he tocado el futuro: aún no he descubierto cómo reflejar los resultados (por ejemplo, el resultado de la ejecución de un comando) que llegan al servidor usando las herramientas estándar de zabbix.
Les recuerdo que todas las fuentes se pueden tomar del repositorio de Git en:
Fuente: habr.com