Esta é a parte final do artigo, aquí está o comezo
A última vez que escribín sobre como implementei a monitorización do dispositivo, agora falaremos da xestión. Nas discusións cos "técnicos" do lado do Cliente, adoito atoparme cunha percepción limitada das capacidades de dispositivos tan pequenos (con poucos recursos de memoria e rendemento), moitos cren que "o máis que necesitamos é enviar un reinicio, por algo máis. en serio mandaremos un equipo”.
Pero a práctica demostra que isto non é totalmente certo. Aquí tes unha pequena lista de tarefas típicas comúns:
- Diagnóstico e resolución de problemas de rede. Detrás do porto Ethernet do teu enrutador normalmente hai outra peza de hardware que ten o seu propio enderezo IP interno. Ás veces, pode (debería) "ping". Ou xestión de túneles: se o túnel de súpeto non se eleva nun enrutador que funciona a través dun módem 3G, pero podemos ver o propio enrutador.
- Mantemento do sistema. Actualización do firmware, actualización do script de servizo.
- Acto de equilibrio. Isto podería chamarse "perversión", pero o concepto de "equilibrista" como, cito, "a capacidade dun artista de circo para manter o equilibrio nunha posición corporal inestable" - encaixa mellor. Tales situacións xorden debido ao orzamento limitado do cliente. A continuación puxen un par de exemplos, pero... Non están directamente relacionados co tema da historia, poñoos nas notas
Monitorización Wi-FiUn tema de moda nos últimos cinco anos, principalmente entre as cadeas federais de venda polo miúdo. Estás paseando tranquilamente polas salas comerciais, e o teu teléfono móbil coa wifi activada, nun intento de "aterse" a algún fío da rede, envía regularmente paquetes de solicitude de proba que poden ser analizados para calcular por ti. : cantas veces chegas a esta tenda, por que motivos?, percorres traxectorias etc. A continuación, recóllense, analízanse os datos, debúxanse mapas térmicos e os xestores "extorsionan" cartos á dirección ou aos investimentos para tales imaxes. Pois de momento.... “non hai cartos, pero aguantas...”, e o resultado (real) xa hai que amosar, comeza a boa vella canción: “Si, si, pois claro que nós. instalará o cis e todo o que queiras, pero agora temos que mostrarlle ao cliente o resultado! Por certo, esquecémonos de dicir que o Cliente permitiunos conectar o noso equipo ao seu punto de acceso a través de Wi-Fi, pero con carácter xeral, como se fósemos clientes convidados”. E por iso temos que facer enrutadores de equilibrio: levántanse varias subinterfaces WiFi, unha das cales se adhire ao punto de acceso, e a segunda monitoriza o ambiente, carga frenéticamente o resultado tcpdump para si mesmo, despois empaqueta o contido do ficheiro nun arquivo e arrisca. morrer por "comer en exceso" intenta cuspir o contido no servidor FTP. Non é de estrañar que o enrutador de equilibrio adoita "romperse" e de algunha maneira teña que ser "resucitado" de forma remota.
raioÉ máis fácil describir a situación aquí con algo como esta declaración do cliente: “Queremos unha rede descentralizada de puntos de acceso que funcione en equipos cuxo modelo non se coñece de antemán, a través de canles, pero cales aínda non coñecemos. Ah, esquecémonos de dicir, non só queremos mostrar publicidade aos clientes, senón tamén analizar todo o que rodea o lugar onde está instalado o hotspot. Non, aínda non sabemos por que, pero resolverémolo, non o dubides, puidemos dar con esta idea”.
E non debemos esquecer que debido a moitas circunstancias previamente descoñecidas, o control debe levarse a cabo en condicións non estándar, cando non podemos conectarnos ao router directamente a través do porto IP: e nos vemos obrigados a simplemente esperar a actividade deste. Se nos abstraemos, o diálogo entre o servidor e o router pódese representar así:
- Router: Ola. Son tal ou tal router, hai tarefas para min?
- Servidor: enrutador tal e tal, eu rexistrarte, que estás vivo. Aquí está o desafío: mostrarme o resultado do comando ifconfig?
- Router: Ola. Son tal ou tal enrutador, a última vez que pediches mostrar o resultado de ifconfig, aquí está. Hai algunha tarefa para min?
- Servidor: enrutador tal e tal, eu rexistrarte, que estás vivo. Non hai tarefas para ti.
A pregunta máis interesante: como pode un enrutador remoto enviar unha certa cantidade de información? Na última parte, describín que, debido aos recursos limitados, o enrutador só ten un wget "depurado", que só funciona a través de GET e nada máis; non hai cliente FTP nin curl. Máis precisamente, necesitamos un método universal, independentemente das características da montaxe de imaxes. Decidín usar wget. Máis precisamente, como "parei" - simplemente non tiña opción :)
Só unha exención de responsabilidadeA miña solución de xestión está funcionando, non moi limitada, e estou seguro de que está mal, aínda que se adapte á maioría dos meus clientes. Como podería facelo con prudencia: escriba unha pequena utilidade que envíe datos binarios POST a través do porto 80. Inclúeo (a utilidade) no firmware do enrutador e acceda a el mediante bash. Pero a realidade é que: a) necesitamos facelo rapidamente b) probablemente teñamos que facer todo no "zoo de enrutadores" existente c) "non facer dano!" — Se o enrutador está funcionando e realizando outras tarefas, intente facer cambios que non afecten á funcionalidade existente.
Pasemos á implementación. Digamos que o seu cliente quere reiniciar o enrutador desde zabbix de forma sinxela e natural, cun "clic do rato". Hoxe comezaremos a describir a implementación con Zabbix.
No menú "Administración" -> "Scripts", engade un novo script. Chamámoslle "Reiniciar", escriba "php /usr/share/zabbix/reboot.php {HOST.HOST}" como comando
Seguinte: Menú "Monitorización" -> "Últimos datos" -> "Prema co botón dereito do rato no nodo de rede desexado". Así será o menú despois de engadir o script.
En consecuencia, poñemos o script reboot.php no directorio /usr/share/zabbix (o teu pode ser diferente, eu uso o directorio raíz zabbixa).
Descargo de responsabilidade de seguridadePara que a explicación sexa máis clara no guión, só uso o ID do enrutador, pero non uso o contrasinal. Non se recomenda facelo na versión de produción! Por que fixen isto: porque a gran pregunta é onde almacenar os contrasinais dos enrutadores? Na propia zabbixe en “datos de inventario”? Práctica controvertida. Alternativamente: restrinxir o acceso externo ao propio ficheiro reboot.php
Ficheiro reboot.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();
?>Iso é todo. A pregunta segue aberta: "como obter o resultado de executar un comando desde o dispositivo". Vexamos a tarefa usando o comando ifconfig como exemplo. Este comando pódese enviar ao dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txtonde:
mensaxe=`ifconfig` — asignamos o resultado da saída do comando ifconfig á variable $message
wget" — o noso script a.php que rexistra os enrutadores e recibe mensaxes deles
u=usuario&p=contrasinal!&m=$mensaxe — credenciais e o valor da variable de solicitude m — asigna o contido da variable $message
-O /tmp/out.txt — Non necesitamos saída ao ficheiro /tmp/out.txt neste caso, pero se non se especifica este parámetro, wget non funciona
Por que isto non funciona?Porque é un posible buraco de seguridade. O erro máis inofensivo que pode ocorrer é se, por exemplo, hai un carácter "&" na saída do seu comando. Polo tanto, é necesario filtrar tanto todo o que se envía desde os enrutadores como todo o que chega ao servidor. Si, teño vergoña, de verdade. Na miña defensa, só podo escribir que todo o artigo está dedicado a como xestionar enrutadores con firmware predefinido e canles de comunicación que non están definidas de antemán.
Ben, un comezo para o futuro: aínda non descubrín como usar as ferramentas estándar zabbix para reflectir os resultados (por exemplo, o resultado de executar un comando) que chegan ao servidor.
Lémbrovos que todas as fontes pódense obter do repositorio de Git en:
Fonte: www.habr.com