Aceasta este partea finală a articolului, aici este începutul
Ultima dată când am scris despre cum am implementat monitorizarea dispozitivelor, acum vom vorbi despre management. În discuțiile cu „tehnicienii” din partea Clientului, întâlnesc adesea o percepție limitată asupra capabilităților unor dispozitive atât de mici (cu resurse de memorie și performanțe reduse), mulți cred că „cel mai mult de care avem nevoie este să trimitem un reboot, pentru ceva mai mult. serios trimitem o echipă” .
Dar practica arată că acest lucru nu este în întregime adevărat. Iată o mică listă de sarcini tipice comune:
- Diagnosticarea rețelei și depanarea. În spatele portului ethernet al routerului dvs. există de obicei o altă piesă hardware care are propria sa adresă IP internă. Uneori, puteți (ar trebui) să îl „ping”. Sau gestionarea tunelului - dacă tunelul nu se ridică brusc pe un router care funcționează printr-un modem 3G, dar putem vedea routerul însuși.
- Întreținerea sistemului. Actualizare firmware, actualizare script de serviciu.
- Act de echilibrare. Acest lucru s-ar putea numi „perversiune”, dar conceptul de „equilibrist” ca, citez, „capacitatea unui artist de circ de a menține echilibrul într-o poziție instabilă a corpului” - se potriveste mai bine. Astfel de situații apar din cauza bugetului limitat al clientului. Mai jos am dat câteva exemple, dar... Nu au legătură directă cu tema poveștii, le-am pus în note
Monitorizare Wi-FiUn subiect la modă în ultimii cinci ani, în principal printre lanțurile federale de retail. Vă plimbați pe îndelete prin platformele de tranzacționare, iar telefonul dvs. mobil cu Wi-Fi pornit, în încercarea de a „lipi” de un fir al rețelei, trimite în mod regulat pachete Probe Request, care pot fi analizate pentru a calcula pentru tu: cât de des vii în acest magazin, din ce motive? mergi pe traiectorii și așa mai departe. Apoi datele sunt culese, analizate, sunt desenate hărți termice, iar managerii „storc” bani de la conducere sau de la investitori pentru astfel de imagini. Ei bine, deocamdată.... „nu sunt bani, dar te ții...”, iar rezultatul (real) trebuie deja arătat, vechea melodie bună începe: „Da, da, atunci bineînțeles că noi va instala cis și tot ce doriți, dar acum trebuie să arătăm clientului rezultatul! Apropo, am uitat să spunem că Clientul ne-a permis să ne conectăm echipamentele la hotspot-ul său prin Wi-Fi, dar în general, la fel ca și cum am fi clienți oaspeți.” Și așa trebuie să facem routere de echilibrare - sunt ridicate mai multe subinterfețe WiFi, dintre care una se agăță de hotspot, iar a doua monitorizează mediul, încarcă frenetic rezultatul tcpdump în sine, apoi împachetează conținutul fișierului într-o arhivă și riscă murind din cauza „mâncării excesive” încearcă să scuipe conținutul pe serverul FTP. Nu este surprinzător că ruterul de echilibrare se „defectează” adesea și cumva trebuie „resuscitat” de la distanță.
RazăEste mai ușor să descrii situația aici cu ceva de genul acestei afirmații din partea clientului: „Ne dorim o rețea descentralizată de hotspot-uri care să funcționeze pe echipamente al căror model nu este cunoscut dinainte, prin canale, dar pe care nu le cunoaștem încă. Oh, am uitat să spunem, nu vrem doar să arătăm reclamă clienților, ci și să analizăm totul în jurul locației în care este instalat hotspot-ul. Nu, încă nu știm de ce, dar ne vom da seama, nu vă îndoiți, am reușit să venim cu această idee.”
Și nu trebuie să uităm că, din cauza multor circumstanțe necunoscute anterior, controlul trebuie efectuat în condiții non-standard, atunci când nu ne putem conecta direct la router prin portul IP: și suntem forțați să așteptăm pur și simplu activitatea de la acesta. Dacă ne abstragem, dialogul dintre server și router poate fi reprezentat astfel:
- router: Buna ziua. Sunt un astfel de router, există sarcini pentru mine?
- Server: router asa si asa, te-am inregistrat, ca esti in viata. Iată provocarea: arată-mi rezultatul comenzii ifconfig?
- router: Buna ziua. Sunt un astfel de router, ultima dată când ați cerut să afișați rezultatul ifconfig, iată-l. Există sarcini pentru mine?
- Server: router asa si asa, te-am inregistrat, ca esti in viata. Nu există sarcini pentru tine.
Cea mai interesantă întrebare: cum poate un router la distanță să trimită o anumită cantitate de informații? În ultima parte, am descris că, din cauza resurselor limitate, router-ul are doar un wget „stripped-down”, care funcționează numai prin GET și nimic altceva; nu există client FTP sau curl. Mai exact, avem nevoie de o metodă universală, indiferent de caracteristicile asamblarii imaginii. M-am hotărât să folosesc wget. Mai precis, cum m-am „oprit” - pur și simplu nu aveam de ales :)
Doar o declinare a răspunderiiSoluția mea de management funcționează, nu este foarte limitată și sunt sigur că este strâmbă, chiar dacă se potrivește majorității clienților mei. Cum ați putea face acest lucru cu înțelepciune - scrieți un mic utilitar care trimite date binare POST prin portul 80. Includeți-l (utilitatea) în firmware-ul routerului și accesați-l folosind bash. Dar realitatea este că: a) trebuie să facem rapid b) probabil că trebuie să facem totul pe „grădina zoologică de routere” existentă c) „nu face rău!” — dacă routerul funcționează și îndeplinește alte sarcini, încercați să faceți modificări care nu vor afecta funcționalitatea existentă.
Să trecem la implementare. Să presupunem că clientul dvs. dorește să repornească routerul de pe zabbix ușor și natural, cu un „clic de mouse”. Astăzi vom începe să descriem implementarea cu Zabbix.
În meniul „Administrare” -> „Scripturi”, adăugați un nou script. Îl numim „Reboot”, introduceți „php /usr/share/zabbix/reboot.php {HOST.HOST}” ca comandă
Următorul: Meniul „Monitorizare” -> „Ultimele date” -> „Clic dreapta pe nodul de rețea dorit”. Așa va arăta meniul după adăugarea scriptului.
În consecință, punem scriptul reboot.php în directorul /usr/share/zabbix (al tău poate fi diferit, eu folosesc directorul rădăcină zabbixa).
Disclaimer privind siguranțaPentru a face explicația mai clară în script, folosesc doar id-ul routerului, dar nu folosesc parola. Nu este recomandat să faceți acest lucru în versiunea de producție! De ce am făcut asta: pentru că marea întrebare este unde să stochezi parolele pentru routere? În zabbixe în sine în „date de inventar”? Practică controversată. Alternativ: restricționați accesul extern la fișierul reboot.php în sine
Fișierul 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();
?>Asta e tot. Întrebarea rămâne deschisă: „cum să obțineți rezultatul executării unei comenzi de pe dispozitiv”. Să ne uităm la sarcină folosind comanda ifconfig ca exemplu. Această comandă poate fi trimisă la dispozitiv:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, unde:
mesaj=`ifconfig` — atribuim rezultatul comenzii ifconfig variabilei $message
wget" — scriptul nostru a.php care înregistrează routerele și primește mesaje de la acestea
u=utilizator&p=parolă!&m=$mesaj — acreditările și valoarea variabilei de solicitare m — atribuie conținutul variabilei $message
-O /tmp/out.txt — nu avem nevoie de ieșire în fișierul /tmp/out.txt în acest caz, dar dacă acest parametru nu este specificat, wget nu funcționează
De ce nu funcționează asta?Pentru că este o posibilă gaură de securitate. Cea mai inofensivă eroare care se poate întâmpla este dacă, de exemplu, există un caracter „&” în rezultatul comenzii tale. Prin urmare, este necesar să se filtreze atât tot ceea ce este trimis de la routere, cât și tot ceea ce vine la server. Da, chiar mi-e rușine. În apărarea mea, pot scrie doar că întregul articol este dedicat modului de gestionare a routerelor cu firmware predefinit și canale de comunicare care nu sunt definite în prealabil.
Ei bine, un început pentru viitor: încă nu mi-am dat seama cum să folosesc instrumentele standard zabbix pentru a reflecta rezultatele (de exemplu, rezultatul executării unei comenzi) care vin pe server.
Vă reamintesc că toate sursele pot fi obținute din depozitul Git la:
Sursa: www.habr.com