Toto je záverečná časť článku, tu je začiatok
Minule som písal o tom, ako som implementoval monitorovanie zariadení, teraz si povieme niečo o správe. Pri diskusiách s „technikmi“ na strane zákazníka sa často stretávam s obmedzeným vnímaním možností takýchto malých zariadení (s nízkymi pamäťovými prostriedkami a výkonom), mnohí sa domnievajú, že „najviac potrebujeme poslať reštart, pre niečo viac vážne, pošleme tím“.
Ale prax ukazuje, že to nie je celkom pravda. Tu je malý zoznam bežných typických úloh:
- Diagnostika siete a riešenie problémov. Za ethernetovým portom vášho smerovača sa zvyčajne nachádza ďalší hardvér, ktorý má svoju vlastnú internú IP adresu. Niekedy to môžete (mali by ste) „pingnúť“. Alebo správa tunela – ak tunel zrazu nestúpa na routeri fungujúcom cez 3G modem, ale vidíme samotný router.
- Údržba systému. Aktualizácia firmvéru, aktualizácia servisného skriptu.
- Vyvažovanie. Dalo by sa to nazvať „zvrátenosťou“, ale pojem „rovnováha“, ako citujem, „schopnosť cirkusového umelca udržať rovnováhu v nestabilnej polohe tela“ - lepšie sedí. Takéto situácie vznikajú v dôsledku obmedzeného rozpočtu zákazníka. Nižšie som uviedol pár príkladov, ale... Nesúvisia priamo s témou príbehu, dávam ich do poznámok
Wi-Fi monitorovanieMódna téma posledných piatich rokov hlavne medzi federálnymi obchodnými reťazcami. Pokojne sa prechádzate po obchodných poschodiach a váš mobilný telefón so zapnutým Wi-Fi, v snahe „prilepiť“ sa k nejakému vláknu siete, pravidelne posiela pakety Probe Request, ktoré možno analyzovať s cieľom vypočítať vy: ako často chodíte do tohto obchodu, z akých dôvodov, chodíte po trajektóriách a podobne. Potom sa údaje zbierajú, analyzujú, kreslia tepelné mapy a manažéri za takéto obrázky „vymáhajú“ peniaze od manažmentu alebo investorov. No zatiaľ.... “peňazí nie sú, ale vydržte...”, a výsledok (reálny) už treba ukázať, začína stará dobrá pesnička: “Áno, áno, tak samozrejme nainštaluje cis a všetko, čo chcete, ale teraz musíme zákazníkovi ukázať výsledok! Mimochodom, zabudli sme povedať, že zákazník nám umožnil pripojiť naše zariadenie k jeho hotspotu cez Wi-Fi, ale vo všeobecnosti, ako keby sme boli hosťami.“ A tak musíme urobiť vyrovnávacie smerovače – zdvihne sa niekoľko podrozhraní WiFi, z ktorých jedno sa prichytí k hotspotu a druhé monitoruje prostredie, horúčkovito nahrá výsledok tcpdump do seba, potom zabalí obsah súboru do archívu a riskuje umierajúci na „prejedanie“ sa snaží vypľuť obsah na FTP serveri. Nie je prekvapujúce, že balančný smerovač sa často „pokazí“ a nejakým spôsobom ho treba „resuscitovať“ na diaľku.
PolomerJe jednoduchšie opísať situáciu tu s niečím ako toto vyhlásenie od zákazníka: „Chceme decentralizovanú sieť hotspotov, ktoré by fungovali na zariadeniach, ktorých model nie je vopred známy, prostredníctvom kanálov, ale ktoré ešte nepoznáme. Och, zabudli sme povedať, nechceme len zobrazovať reklamu klientom, ale aj analyzovať všetko okolo miesta, kde je hotspot nainštalovaný. Nie, ešte nevieme prečo, ale prídeme na to, o tom nepochybujte, boli sme schopní prísť s týmto nápadom."
Netreba zabúdať ani na to, že kvôli množstvu doteraz neznámych okolností musí kontrola prebiehať v neštandardných podmienkach, kedy sa nevieme pripojiť k routeru priamo cez IP: port a sme nútení jednoducho čakať na aktivitu z neho. Ak sa abstrahujeme, dialóg medzi serverom a routerom môže byť reprezentovaný takto:
- router: Ahoj. Som taký a taký router, sú pre mňa nejaké úlohy?
- Server: router taký a taký, zaregistroval som ťa, že žiješ. Tu je výzva: ukážte mi výsledok príkazu ifconfig?
- router: Ahoj. Som taký a taký router, minule si žiadal ukázať výsledok ifconfig, tu je. Sú pre mňa nejaké úlohy?
- Server: router taký a taký, zaregistroval som ťa, že žiješ. Nie sú pre vás žiadne úlohy.
Najzaujímavejšia otázka: ako môže vzdialený smerovač odoslať určité množstvo informácií? V minulej časti som popísal, že z dôvodu obmedzených zdrojov má router iba „ostrihaný“ wget, ktorý funguje len cez GET a nič iné, nie je tam žiadny FTP klient ani curl. Presnejšie povedané, potrebujeme univerzálnu metódu bez ohľadu na vlastnosti zostavy obrazu. Rozhodol som sa používať wget. Presnejšie, ako som sa „zastavil“ - jednoducho som nemal na výber :)
Len odmietnutie zodpovednostiMoje riešenie správy funguje, nie je príliš obmedzené a som si istý, že je pokrivené, aj keď vyhovuje väčšine mojich zákazníkov. Ako by ste to mohli urobiť múdro - napíšte malý nástroj, ktorý odosiela binárne údaje POST cez port 80. Zahrňte ho (nástroj) do firmvéru smerovača a pristupujte k nemu pomocou bash. Ale realita je taká, že: a) musíme rýchlo b) pravdepodobne musíme urobiť všetko na existujúcej „zoo routerov“ c) „neškodiť!“ — ak router funguje a vykonáva iné úlohy, pokúste sa vykonať zmeny, ktoré neovplyvnia existujúcu funkčnosť.
Prejdime k implementácii. Povedzme, že váš zákazník chce reštartovať smerovač zo zabbix jednoducho a prirodzene, „kliknutím myšou“. Dnes začneme popisovať implementáciu so Zabbixom.
V ponuke „Správa“ -> „Skripty“ pridajte nový skript. Hovoríme tomu „Reboot“, zadajte „php /usr/share/zabbix/reboot.php {HOST.HOST}“ ako príkaz
Ďalej: Ponuka „Monitorovanie“ -> „Najnovšie údaje“ -> „Kliknite pravým tlačidlom myši na požadovaný sieťový uzol“. Takto bude menu vyzerať po pridaní skriptu.
Podľa toho sme skript reboot.php umiestnili do adresára /usr/share/zabbix (ten váš môže byť iný, ja používam koreňový adresár zabbixa).
Vyhlásenie o bezpečnostiAby bolo vysvetlenie v skripte jasnejšie, používam iba ID smerovača, ale nepoužívam heslo. Neodporúča sa to robiť v produkčnej verzii! Prečo som to urobil: pretože hlavnou otázkou je, kde ukladať heslá pre smerovače? V samotnom zabbixe v „údajoch o zásobách“? Kontroverzná prax. Prípadne: obmedzte externý prístup k samotnému súboru reboot.php
Súbor 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();
?>To je všetko. Otázka zostáva otvorená: „ako získať výsledok vykonania príkazu zo zariadenia“. Pozrime sa na úlohu pomocou príkazu ifconfig ako príkladu. Tento príkaz je možné odoslať do zariadenia:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, kde:
message=`ifconfig` — výsledok výstupu príkazu ifconfig priradíme premennej $message
wget" — náš skript a.php, ktorý registruje smerovače a prijíma od nich správy
u=user&p=heslo!&m=$správa — poverenia a hodnota premennej požiadavky m — priradí obsah premennej $message
-O /tmp/out.txt — v tomto prípade nepotrebujeme výstup do súboru /tmp/out.txt, ale ak tento parameter nie je zadaný, wget nebude fungovať
Prečo to nefunguje?Pretože je to potenciálna bezpečnostná diera. Najnebezpečnejšia chyba, ktorá sa môže stať, je, ak je napríklad vo výstupe vášho príkazu znak „&“. Preto je potrebné filtrovať všetko, čo sa odosiela zo smerovačov, aj všetko, čo prichádza na server. Áno, hanbím sa, naozaj. Na svoju obranu môžem len napísať, že celý článok je venovaný tomu, ako spravovať routery s vopred nedefinovaným firmvérom a komunikačnými kanálmi.
No, začiatok do budúcnosti: Ešte som neprišiel na to, ako použiť štandardné nástroje zabbix na vyjadrenie výsledkov (napríklad výsledok vykonania príkazu), ktoré prichádzajú na server.
Pripomínam vám, že všetky zdroje je možné získať z úložiska Git na adrese:
Zdroj: hab.com