Esta é a parte final do artigo, aqui está o começo
Da última vez que escrevi sobre como implementei o monitoramento de dispositivos, agora falaremos sobre gerenciamento. Nas discussões com “técnicos” do lado do Cliente, deparo-me muitas vezes com uma percepção limitada das capacidades de dispositivos tão pequenos (com poucos recursos de memória e desempenho), muitos acreditam que “o máximo que precisamos é enviar um reboot, para algo mais sério vamos mandar uma equipe” .
Mas a prática mostra que isso não é inteiramente verdade. Aqui está uma pequena lista de tarefas típicas comuns:
- Diagnóstico e solução de problemas de rede. Atrás da porta Ethernet do seu roteador geralmente há outra peça de hardware que possui seu próprio endereço IP interno. Às vezes, você pode (deveria) fazer “ping” nele. Ou gerenciamento de túnel - se o túnel não subir repentinamente em um roteador operando através de um modem 3G, mas pudermos ver o próprio roteador.
- Manutenção de sistema. Atualização de firmware, atualização de script de serviço.
- Ato de equilíbrio. Isto poderia ser chamado de “perversão”, mas o conceito de “equilibrista” como, cito, “a capacidade de um artista de circo de manter o equilíbrio em uma posição corporal instável” - cabe melhor. Tais situações surgem devido ao orçamento limitado do cliente. Abaixo dei alguns exemplos, mas... Eles não estão diretamente relacionados ao tema da história, coloquei nas notas
Monitoramento Wi-FiTema que está na moda nos últimos cinco anos, principalmente entre as redes varejistas federais. Você está passeando tranquilamente pelos pregões, e seu celular com Wi-Fi ligado, na tentativa de “grudar” em algum thread da rede, envia regularmente pacotes de Probe Request, que podem ser analisados para calcular você: com que frequência você vem a essa loja, por que motivos, você percorre trajetórias e assim por diante. Em seguida, os dados são recolhidos, analisados, mapas de calor são desenhados e os gestores “extorquim” dinheiro da administração ou dos investidores por tais imagens. Bom, por enquanto.... “não tem dinheiro, mas aguenta...”, e o resultado (real) já precisa ser mostrado, começa a boa e velha canção: “Sim, sim, então é claro que a gente vou instalar o cis e tudo que você quiser, mas agora precisamos mostrar ao Cliente o resultado! Aliás, esquecemos de dizer que o Cliente nos permitiu ligar o nosso equipamento ao seu hotspot via Wi-Fi, mas de forma geral, como se fôssemos clientes convidados.” E então temos que fazer o balanceamento dos roteadores - várias subinterfaces WiFi são levantadas, uma das quais se apega ao ponto de acesso e a segunda monitora o ambiente, carrega freneticamente o resultado do tcpdump para si mesmo e, em seguida, compacta o conteúdo do arquivo em um arquivo e arrisca morrendo de “comer demais” tenta cuspir o conteúdo do servidor FTP. Não é de surpreender que o roteador de balanceamento frequentemente “quebre” e de alguma forma precise ser “ressuscitado” remotamente.
RaioÉ mais fácil descrever a situação aqui com algo como esta declaração do cliente: “Queremos uma rede descentralizada de hotspots que funcione em equipamentos cujo modelo não é conhecido antecipadamente, através de canais, mas quais ainda não sabemos. Ah, esquecemos de dizer, não queremos apenas mostrar publicidade aos clientes, mas também analisar tudo ao redor do local onde o hotspot está instalado. Não, ainda não sabemos porquê, mas vamos descobrir, não duvidem, conseguimos ter esta ideia.”
E não devemos esquecer que devido a muitas circunstâncias até então desconhecidas, o controle deve ser realizado em condições atípicas, quando não podemos nos conectar ao roteador diretamente através da porta IP: e somos forçados a simplesmente aguardar a atividade dele. Se nos abstrairmos, o diálogo entre o servidor e o roteador pode ser representado assim:
- Router: Olá. Eu sou tal e tal roteador, há alguma tarefa para mim?
- Servidor: roteador tal e tal, eu registrei você, que você está vivo. Aqui está o desafio: mostre-me o resultado do comando ifconfig?
- Router: Olá. Eu sou tal e tal roteador, da última vez você pediu para mostrar o resultado do ifconfig, aqui está. Há alguma tarefa para mim?
- Servidor: roteador tal e tal, eu registrei você, que você está vivo. Não há tarefas para você.
A questão mais interessante: como um roteador remoto pode enviar uma certa quantidade de informações? Na última parte, descrevi que devido aos recursos limitados, o roteador possui apenas um wget “despojado”, que funciona apenas via GET e nada mais; não há cliente FTP ou curl. Mais precisamente, precisamos de um método universal, independentemente das características de montagem da imagem. Decidi usar o wget. Mais precisamente, como “parei” - simplesmente não tive escolha :)
Apenas um avisoMinha solução de gerenciamento está funcionando, não muito limitada, e tenho certeza de que é torta, mesmo que seja adequada para a maioria dos meus clientes. Como você poderia fazer isso com sabedoria - escreva um pequeno utilitário que envie dados binários POST pela porta 80. Inclua-o (o utilitário) no firmware do roteador e acesse-o usando o bash. Mas a realidade é que: a) precisamos fazê-lo rapidamente b) provavelmente precisaremos fazer tudo no “zoológico de roteadores” existente c) “não causar danos!” — se o roteador estiver funcionando e executando outras tarefas, tente fazer alterações que não afetem a funcionalidade existente.
Vamos passar para a implementação. Digamos que seu cliente queira reiniciar o roteador do zabbix de forma fácil e natural, com um “clique do mouse”. Hoje começaremos a descrever a implementação com Zabbix.
No menu “Administração” -> “Scripts”, adicione um novo script. Chamamos isso de “Reboot”, digite “php /usr/share/zabbix/reboot.php {HOST.HOST}” como um comando
Próximo: Menu “Monitoramento” -> “Dados mais recentes” -> “Clique com o botão direito no nó da rede desejado.” Esta é a aparência do menu após adicionar o script.
Assim, colocamos o script reboot.php no diretório /usr/share/zabbix (o seu pode ser diferente, eu uso o diretório raiz do zabbixa).
Isenção de responsabilidade de segurançaPara deixar a explicação mais clara no script, utilizo apenas o id do roteador, mas não utilizo a senha. Não é recomendado fazer isso na versão de produção! Por que fiz isso: porque a grande questão é onde armazenar as senhas dos roteadores? No próprio zabbixe em “dados de inventário”? Prática controversa. Alternativamente: restrinja o acesso externo ao próprio arquivo reboot.php
Arquivo reiniciar.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();
?>Isso é tudo. A questão permanece em aberto: “como obter o resultado da execução de um comando do dispositivo”. Vejamos a tarefa usando o comando ifconfig como exemplo. Este comando pode ser enviado para o dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, onde:
mensagem=`ifconfig` — atribuímos o resultado da saída do comando ifconfig à variável $message
wget" — nosso script a.php que registra roteadores e recebe mensagens deles
u=usuário&p=senha!&m=$mensagem — credenciais e o valor da variável de solicitação m — atribui o conteúdo da variável $message
-O /tmp/out.txt — não precisamos de saída para o arquivo /tmp/out.txt neste caso, mas se este parâmetro não for especificado, o wget não funciona
Por que isso não funciona?Porque é uma potencial falha de segurança. O erro mais inofensivo que pode acontecer é se, por exemplo, houver um caractere “&” na saída do seu comando. Portanto, é necessário filtrar tanto tudo o que é enviado dos roteadores quanto tudo o que chega ao servidor. Sim, estou com vergonha, de verdade. Em minha defesa, só posso escrever que todo o artigo é dedicado a como gerenciar roteadores com firmware predefinido e canais de comunicação que não são definidos antecipadamente.
Bem, um começo para o futuro: ainda não descobri como usar as ferramentas padrão do Zabbix para refletir os resultados (por exemplo, o resultado da execução de um comando) que chegam ao servidor.
Lembro que todas as fontes podem ser obtidas no repositório Git em:
Fonte: habr.com