Aquesta és la part final de l'article, aquí està el principi
La darrera vegada que vaig escriure sobre com vaig implementar la supervisió de dispositius, ara parlarem de gestió. En les discussions amb "tecnics" per part del client, sovint em trobo amb una percepció limitada de les capacitats de dispositius tan petits (amb pocs recursos de memòria i rendiment), molts creuen que "el màxim que necessitem és enviar un reinici , per una cosa més seriosa - enviarem una brigada" .
Però la pràctica demostra que això no és del tot cert. Aquí teniu una petita llista de tasques habituals:
- Diagnòstic i resolució de problemes de xarxa. Darrere del port Ethernet del vostre encaminador, sol "viu" una altra peça de ferro que té la seva pròpia adreça IP interna. De vegades, es pot (hauria) de fer "ping". O gestió del túnel: si el túnel de sobte no s'aixeca a l'encaminador que treballa a través del mòdem 3G, però veiem el propi encaminador.
- Servei del sistema. Actualització del firmware, actualització de scripts de servei.
- Equilibristics. Això es podria anomenar "perversions", però el concepte de "funàmbul" com, cito, "la capacitat d'un artista de circ per mantenir l'equilibri en una posició corporal inestable" - encaixa millor. Aquestes situacions sorgeixen a causa del pressupost limitat del client. Vaig posar un parell d'exemples a continuació, però des de llavors no estan directament relacionats amb el tema de la història, els poso a les notes
monitorització wifiUn tema de moda durant els darrers cinc anys, principalment entre les cadenes de comerç al detall federals. Esteu caminant lentament per les sales de negociació i el vostre telèfon mòbil amb Wi-Fi encès, en un intent d'"enganxar-se" a algun fil de la xarxa, envia regularment paquets de sol·licitud de sondeig que es poden analitzar per calcular-los per vosaltres. : amb quina freqüència vens a aquesta botiga, per quines trajectòries camina i així successivament. A més, es recullen, s'analitzen les dades, es dibuixen mapes de calor i els gestors "eliminen" els diners de la direcció o dels inversors per a aquestes imatges. Mentrestant... “no hi ha diners, però aguanteu...”, i el resultat (real) ja s'hauria de mostrar, la bona vella cançó “Sí, sí, doncs és clar que proveirem ciscos i el que vulguis, però ara hem de mostrar el resultat al client! Per cert, es van oblidar de dir que el Client va permetre que el nostre equip es connectés al seu punt d'accés Wi-Fi, però de manera general, com si fóssim clients convidats. I ara heu de fer encaminadors equilibristes: s'aixequen diverses subinterfícies WiFi, una de les quals s'aferra a l'hotspot i la segona supervisa l'entorn, descarrega frenèticament el resultat de tcpdump en si mateix, després empaqueta el contingut del fitxer en un arxiu i corre el risc de morir per "menjar en excés" intentant escopir el contingut al servidor ftp. No és d'estranyar que l'encaminador equilibrista sovint "s'avaria" i d'alguna manera s'hagi de "reanimar" de forma remota.
RàdioAquí és més fàcil descriure la situació amb alguna cosa com aquesta declaració del client: “Volem una xarxa descentralitzada de punts d'accés que funcioni en equips el model dels quals no es coneix per endavant, a través de canals, però quins encara no coneixem. Ah, ens vam oblidar de dir, no només volem mostrar anuncis als clients, sinó també analitzar tot el que hi ha al voltant del lloc d'instal·lació de l'hotspot. No, encara no sabem per què, però ens en sortirem, no ho dubtis, hem pogut fer aquesta idea”.
I no hem d'oblidar que per moltes circumstàncies d'incertesa per endavant, la gestió s'ha de dur a terme en condicions no estàndard, quan no ens podem connectar directament al router a través del port ip: i ens veiem obligats a esperar simplement que aparegui activitat des de això. Si fem abstractes, el diàleg entre el servidor i l'encaminador es pot representar així:
- Router: Hola. Sóc tal o tal encaminador, hi ha alguna tasca per a mi?
- Servidor: tal o tal router, et vaig registrar que estàs viu. Aquest és el repte: mostrar-me la sortida de l'ordre ifconfig?
- Router: Hola. Sóc tal encaminador, la darrera vegada que vau demanar que mostrés el resultat d'ifconfig, aquí el teniu. Hi ha tasques per a mi?
- Servidor: tal o tal router, et vaig registrar que estàs viu. No hi ha tasques per a tu.
La pregunta més interessant és: com pot un encaminador remot enviar una certa quantitat d'informació? A l'última part, vaig descriure que l'encaminador, a causa dels recursos limitats, només té un wget "despullat", que només funciona mitjançant GET i res més, no hi ha client ftp ni curl. Més precisament, necessitem una manera universal, independentment de les característiques del conjunt de la imatge. Em vaig decidir a utilitzar wget. Més precisament, com "s'ha aturat": no tenia cap opció 🙂
Reserva immediataLa meva solució de gestió funciona, no molt limitada, i estic segur que està malament, encara que s'adapti a la majoria dels meus clients. Com seria possible fer-ho amb prudència: escriviu una petita utilitat que enviï dades binàries mitjançant POST a través del port 80. Incloeu-lo (utilitat) al firmware de l'encaminador i utilitzeu bash per accedir-hi. Però la realitat és que: a) heu de fer-ho ràpidament b) probablement haureu de fer-ho tot al "zoo d'encaminadors" existent c) "no feu mal!" - si l'encaminador està funcionant i realitza altres tasques, intenteu fer canvis que no afectin la funcionalitat existent.
Passem a la implementació. Suposem que el vostre client vol que zabbix reiniciï l'encaminador de manera fàcil i natural, amb un "clic del ratolí". Avui començarem la descripció de la implementació amb zabbix.
Al menú "Administració" -> "Scripts" afegiu un nou script. L'anomenem "Reboot", com a ordre escrivim "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Següent: Menú "Supervisió" -> "Últimes dades" -> "Feu clic amb el botó dret a l'amfitrió desitjat". Així es veurà el menú després d'afegir l'script.
En conseqüència, posem l'script reboot.php al directori /usr/share/zabbix (pot ser diferent per a tu, jo faig servir el directori arrel zabbixa).
Exempció de responsabilitat de seguretatPer a la claredat de l'explicació a l'script, només faig servir l'identificador de l'encaminador, però no faig servir la contrasenya. A la versió de treball, això no es recomana! Per què vaig fer això: perquè la gran pregunta és on emmagatzemar les contrasenyes dels encaminadors? En zabbixe mateix en "inventari"? Pràctica contradictòria. Com a opció: restringeix l'accés extern al propi fitxer reboot.php
fitxer 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();
?>En realitat tot. La pregunta "com obtenir el resultat de l'execució de l'ordre des del costat del dispositiu" roman oberta. Considerem la tasca utilitzant l'ordre ifconfig com a exemple. Es pot enviar l'ordre següent al dispositiu:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txton:
missatge=`ifconfig` - assignem el resultat de la sortida de l'ordre ifconfig a la variable $message
wget" - el nostre script a.php que registra els encaminadors i rep missatges d'ells
u=usuari&p=contrasenya!&m=$missatge - credencials i el valor de la variable de consulta m - assigna el contingut de la variable $message
-O /tmp/out.txt - No necessitem la sortida al fitxer /tmp/out.txt en aquest cas, però si aquest paràmetre no s'especifica, wget no funciona
Per què això funciona malamentPerquè és un possible forat de seguretat. L'error més innocu que pot passar és si la sortida de la vostra comanda, per exemple, conté el símbol "&". Per tant, cal filtrar tot el que s'envia des dels encaminadors i tot el que arriba al servidor. Sí, em fa vergonya, de veritat. En la meva defensa, només puc escriure que tot l'article està dedicat a com gestionar encaminadors amb microprogramari no definit, amb canals de comunicació no definits.
Bé, he parlat del futur: encara no he esbrinat com reflectir els resultats (per exemple, el resultat d'una execució d'ordres) que arriben al servidor mitjançant eines estàndard de zabbix.
Us recordo que totes les fonts es poden extreure del repositori Git a:
Font: www.habr.com